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

Eliot Miranda eliot.miranda at gmail.com
Sun Mar 7 05:25:03 UTC 2010


On Thu, Mar 4, 2010 at 3:05 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Andreas Raab wrote:
>
>> On 3/4/2010 12:33 PM, Juan Vuletich wrote:
>>
>>> I believe #isKindOf: is really bad. Reasons for this are given in
>>> http://userweb.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf . This was
>>> also discussed here, you can google for the name of the pdf in the
>>> archives.
>>>
>>> In the Cuis implementation of Object>>#is: there is no call to
>>> #isKindOf:. The idea is to ask for a protocol, not for inheritance.
>>>
>>
>> But inheritance implies protocol. There is nothing wrong with asking for
>> protocol conformance based on inheritance; it is the same as implementing
>> isNumber in class Number for the purpose of having subclasses inherit that.
>>
>> The implementation that I've proposed is making that point. Thus (42 is:
>> #Number) returns true, since 42 conforms to the Number protocol. If you had
>> some other class that conforms to the number protocol without subclassing
>> it, it is free to implement, e.g.,
>>
>> ComplexNumericRepresentative>>is: aSymbol
>>    "I conform to the number protocol"
>>    ^aSymbol == #Number or:[super is: aSymbol]
>>
>> As a consequence, the #is: test is not an inheritance test at all.
>>
>> Cheers,
>>  - Andreas
>>
>
> What you say is right. The reasons for me not doing it that way are perhaps
> subtle and aesthetic. I prefer making it as clear as possible that this is
> not about inheritance but protocol.


If is: is about protocol not inheritance (a position I would support) then
is: is a very bad selector.  canUnderstand: and respondsTo: taken.
 supports: has applications in civil engineering simulations.  What about
comprehends:?  "Too long" you say; "is: is neat and short" you say.  But it
is also hopelessly ambiguous.  What about groks: ? ;)

Seriously, can we find something better than is?  Or perhaps it can be in
the argument, where one would use "has: #MorphProtocol" instead of the
ambiguous "is: #Morph"? (obvious problems implementing Andreas' base case
efficiently).

At the very least the implementation of is: needs to include a decent
comment explaining the convention.


> I also think that my approach is easier to explain and understand. Besides
> I don't like it looking like there are "special" or "privileged" classes or
> hierarchies. Perhaps more important, I prefer not having "implicit" protocol
> conformance without anybody declaring (for example) that #BorderedMorph is
> now considered a protocol. In addition, I believe that this should be used
> only when really needed. In general, a better design might make all these
> queries unneeded. So, forcing people to declare their protocols might
> discourage abuse.
>
> Anyway, I think both solutions are acceptable and it comes down to taste.
>
> Cheers,
> Juan Vuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100306/3ea1f458/attachment.htm


More information about the Squeak-dev mailing list