[squeak-dev] Re: Object>>#is:? (was: Re: PackageDependencyTest)
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
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.
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
More information about the Squeak-dev