2010/3/14 Stéphane Rollandin <lecteur at zogotounga.net>:
>> model itemsDo: [:item |
>>    self addMorph: (item asMorphIn: self) ]
>
> this one seems the right one for me, although it wouldn't hurt if the morph
> purpose was stated even more explicitely:
>
> model itemsDo: [:item |
>     self addMorph: (item asMorphItemIn: self) ]
>

yes, i am also thought about specializing it like:

 self addMorph: (item asMorphInList: self)
or
 self addMorph: (item asMorphInMenu: self)
and so on..
keep in mind, that you need to make all objects to respond to such messages,
which leads to explosion of such methods and their implementations in
Object class
and many of its subclasses.

Too bad, smalltalk doesn't have multiple dispatch, so i cant define a
single method for a number of method's arguments, not just for
receiver. Then a method lookup would be based on two objects:
list + compiled method
menu + string
etc.

But its still possible when using a single dispatch, just specialize later:

when container sending:
   item asMorphIn: container

a receiver implements it as:
^ container morphForCompiledMethod: self

so, then container chooses, which morph could be used to represent a
compiled method in itself.
The problem, that in this case, one should add such method in a
container class.
Which obviously creates a dilemma, since decision, what kind of morph
should represent an item is equally shared between container and item,
while using only a single side, to be responsible for it, creating a
discrimination.

> my 2 cents
>
> Stef
>


-- 
Best regards,
Igor Stasenko AKA sig.