[squeak-dev] Use of #asMorph

Igor Stasenko siguctua at gmail.com
Sun Mar 14 10:45:05 UTC 2010

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)
 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

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

> my 2 cents
> Stef

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list