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