<br><br><div class="gmail_quote">On Thu, Mar 4, 2010 at 3:05 PM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">Andreas Raab wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 3/4/2010 12:33 PM, Juan Vuletich wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I believe #isKindOf: is really bad. Reasons for this are given in<br>
<a href="http://userweb.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf" target="_blank">http://userweb.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf</a> . This was<br>
also discussed here, you can google for the name of the pdf in the<br>
archives.<br>
<br>
In the Cuis implementation of Object>>#is: there is no call to<br>
#isKindOf:. The idea is to ask for a protocol, not for inheritance.<br>
</blockquote>
<br>
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.<br>
<br>
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.,<br>
<br>
ComplexNumericRepresentative>>is: aSymbol<br>
"I conform to the number protocol"<br>
^aSymbol == #Number or:[super is: aSymbol]<br>
<br>
As a consequence, the #is: test is not an inheritance test at all.<br>
<br>
Cheers,<br>
- Andreas<br>
</blockquote>
<br></div></div>
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. </blockquote><div><br></div><div>
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: ? ;)</div>
<div><br></div><div>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).</div>
<div><br></div><div>At the very least the implementation of is: needs to include a decent comment explaining the convention.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<br>
Anyway, I think both solutions are acceptable and it comes down to taste.<br>
<br>
Cheers,<br><font color="#888888">
Juan Vuletich<br>
<br>
</font></blockquote></div><br>