"Theming" dictionaries?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

"Theming" dictionaries?

Offray Vladimir Luna Cárdenas-2
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



Reply | Threaded
Open this post in threaded view
|

Re: "Theming" dictionaries?

Esteban A. Maringolo
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,

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



Reply | Threaded
Open this post in threaded view
|

Re: "Theming" dictionaries?

Richard Sargent
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,

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



Reply | Threaded
Open this post in threaded view
|

Re: "Theming" dictionaries?

Esteban A. Maringolo
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

Reply | Threaded
Open this post in threaded view
|

Re: "Theming" dictionaries?

Offray Vladimir Luna Cárdenas-2

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