[squeak-dev] Re: Object>>#is:? (was: Re: PackageDependencyTest)
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
>>> 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.
>> - 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
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.
> Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev