[squeak-dev] Re: Object>>#is:? (was: Re: PackageDependencyTest)

Juan Vuletich juan at jvuletich.org
Thu Mar 4 21:26:00 UTC 2010

Stéphane Rollandin wrote:
>> Same as before. The only classes that should ever know about the concept
>> of what your uncle likes are those in package MyUncle. The current
>> implementation in Morph is perfectly good for that. If used properly,
>> this actually decreases the need for overrides. No method in Morph, in
>> any package, should know about your uncle or your cup of tea.
> Ok, I see. We actually have different ideas about software design :)
> That's ok, then. If there is a consensus that good Smalltalk design is 
> like you say (extension methods should be avoided, etc.) then I have 
> nothing to object. I will just continue silently in my own, parallel 
> style.

Well, I don't know if there is any consensus. After all, it is a pretty 
new idea AFAIK and I'm the only one who actually used it. I'm just 
describing a style that I like, and that works for me. Maybe a consensus 
starts to be built after this discussion.

>> I guess you meant 'implementors'
> yes :)
>> you just ask for senders of #Beautiful and you get an exact answer,
>> without any spurious classes answering false.
> hmm.. by doing this you just load the mere presence of a Symbol in a 
> method source with a new semantic charge. I don't like this very 
> much... but again, it's a matter of taste in design.
> best,
> Stef

You can check a bit the symbols in Cuis implementors of #is: and senders 
of them. Maybe you like it.

Using senders to find methods having to do with symbols that mean, for 
example, a possible aspect or status of some object, is a pretty 
standard practice. See for example senders of 
#messageCategorySelectionChanged, #errorOnStep, #doesButtonAction. Of 
course, the symbol being there is not enough. You also need to read the 

Juan Vuletich

More information about the Squeak-dev mailing list