"Theming" dictionaries?
Hi, As some of you may know, I'm a "savage coder" who learned Smalltalk/Pharo by himself, of course thanks to communities, books and videos, but without formal training or peers in the same country and guided mostly by necessity. All this to say that this maybe kind of a silly question. Anyway, we have this project called Minipedia[1], that imports Wikipedia articles and their history. A Minipedia language there, is just a dictionary, where the key is the language two letters code and the value for each key is an array of article titles. There is any way to specialize a Dictionary to tell it, name your 'key' as language and your 'value' as 'titles'? [1] https://mutabit.com/repos.fossil/minipedia/ Thanks, Offray
I'm not sure I fully understand your question. But Dictionaries expect its elements to respond to #key/#value messages, and in the case of Pharo Dictionary is tightly bound to the Association class (and the #-> selector), so there is no way to subclassify Dictionary and specify the class of its elements. Otherwise you could subclassify Dictionary and have its elements to be instances of "MinipediaLanguage", that is polymorphic with Association but have language/titles instead of key/value. I don't see the need for it, though. Esteban A. Maringolo On Wed, Feb 19, 2020 at 1:49 PM Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
Hi,
As some of you may know, I'm a "savage coder" who learned Smalltalk/Pharo by himself, of course thanks to communities, books and videos, but without formal training or peers in the same country and guided mostly by necessity. All this to say that this maybe kind of a silly question.
Anyway, we have this project called Minipedia[1], that imports Wikipedia articles and their history. A Minipedia language there, is just a dictionary, where the key is the language two letters code and the value for each key is an array of article titles. There is any way to specialize a Dictionary to tell it, name your 'key' as language and your 'value' as 'titles'?
[1] https://mutabit.com/repos.fossil/minipedia/
Thanks,
Offray
See below. On Wed, Feb 19, 2020 at 8:49 AM Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
Hi,
As some of you may know, I'm a "savage coder" who learned Smalltalk/Pharo by himself, of course thanks to communities, books and videos, but without formal training or peers in the same country and guided mostly by necessity. All this to say that this maybe kind of a silly question.
Anyway, we have this project called Minipedia[1], that imports Wikipedia articles and their history. A Minipedia language there, is just a dictionary, where the key is the language two letters code and the value for each key is an array of article titles. There is any way to specialize a Dictionary to tell it, name your 'key' as language and your 'value' as 'titles'?
There are several ways, depending on your intention. If you intend that the full Dictionary and Collection API is available to all the places where this artefact will be used, you can add extensions to the Dictionary class to provide alias accessing methods or you can also subclass Dictionary and only have your aliases (and whatever API) visible only to consumers of that class. The former is a quick and dirty approach. The latter is better, since every Dictionary is NOT a language keyed collection of article. If you want to have a limited API, you wrap a dictionary with a new class that exposes just the API you desire consumers to use. In general, inheritance is often overused or/ misused. Composition is usually a better technique unless you want the full API of the hierarchy to be available and used.
[1] https://mutabit.com/repos.fossil/minipedia/
Thanks,
Offray
On Wed, Feb 19, 2020 at 2:09 PM Richard Sargent <richard.sargent@gemtalksystems.com> wrote:
If you want to have a limited API, you wrap a dictionary with a new class that exposes just the API you desire consumers to use.
In general, inheritance is often overused or/ misused. Composition is usually a better technique unless you want the full API of the hierarchy to be available and used.
+1 to this. Inheriting means accepting the "interface contract" of being able to respond to all the messages understood by its superclasses. It also limits your model to future refactorings and modifications. I rarely, if ever, sub-classify any "base" class for domain modelling, and more so in the case of Collection classes, and when I had to deal with domain classes that did that, it always caused more problems than solutions. Regards, Esteban A. Maringolo
On 19/02/20 12:15 p. m., Esteban Maringolo wrote:
On Wed, Feb 19, 2020 at 2:09 PM Richard Sargent <richard.sargent@gemtalksystems.com> wrote:
If you want to have a limited API, you wrap a dictionary with a new class that exposes just the API you desire consumers to use.
In general, inheritance is often overused or/ misused. Composition is usually a better technique unless you want the full API of the hierarchy to be available and used. +1 to this.
Inheriting means accepting the "interface contract" of being able to respond to all the messages understood by its superclasses. It also limits your model to future refactorings and modifications.
I rarely, if ever, sub-classify any "base" class for domain modelling, and more so in the case of Collection classes, and when I had to deal with domain classes that did that, it always caused more problems than solutions.
Regards,
Esteban A. Maringolo
Thanks for all your answers in the thread. I think that I see how this can be done now. Cheers, Offray
participants (3)
-
Esteban Maringolo -
Offray Vladimir Luna Cárdenas -
Richard Sargent