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

Juan Vuletich juan at jvuletich.org
Thu Mar 4 21:12:15 UTC 2010


Stéphane Rollandin wrote:
> Le 04/03/2010 21:42, Juan Vuletich a écrit :
>> Stéphane Rollandin wrote:
>>>
>>> ...
>>> let's now consider MySpecializedMorph, a subclass of MyMorph that I
>>> *do not* want to be considered as MyMorph:
>>>
>>> is: aSymbol
>>>      (super is: aSymbol and: [aSymbol =~ #MyMorph])
>>>          or: [aSymbol == #MySpecializedMorph]) ifTrue: [^ true].
>>>      ^ false
>>>
>>> see the problem ?
>>
>> Yes, I see it. As I see it, #is: is for asking about conformance to a
>> certain protocol. And your MySpecializedMorph does know what protocols
>> it conforms. So it can implement something like:
>>
>> is: aSymbol
>>      aSymbol == #Morph ifTrue: [^true].
>>      aSymbol == #MySpecializedMorph ifTrue: [^true].
>>      ^false
>
> ok; but then if we want to add another protocol true for all Morphs, 
> we will have to go back to MySpecializedMorph>>#is: to add it there.

Yes. However, as others said, making a subclass that does not follow the 
is-a rule is a bad idea. It will need to have special care with 
inherited stuff in many places, not just #is: .

> as I say in another parallel message, if this new protocol belongs to 
> another package, that makes #is: an immediate source of conflict 
> between packages.

In my opinion, overrides should be forbidden for this very reason. But 
that's another discussion. And having to use inheritance properly is the 
smallest inconvenience of doing it.

>
> #is: becomes an attractor, a fixed point for all protocols, dispatched 
> on all classes and having to support all packages. it's another form 
> of the God class: it's the God method for protocols. this is not OOP 
> as I understand (and practice) it.
>
> regards,
>
> Stef 

Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list