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 <[hidden email]> wrote: Hi, |
Administrator
|
In reply to this post by Offray Vladimir Luna Cárdenas-2
See below. On Wed, Feb 19, 2020 at 8:49 AM Offray Vladimir Luna Cárdenas <[hidden email]> wrote: Hi, 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.
|
On Wed, Feb 19, 2020 at 2:09 PM Richard Sargent
<[hidden email]> 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 > <[hidden email]> 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 |
Free forum by Nabble | Edit this page |