<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 4, 2015 at 4:49 PM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>> >> If #isDictionary refers to particular API and behaviors, one could<br>
>> >> argue that a BTree should answer true to #isDictionary, because it has<br>
>> >> similar API and behaviors. In the context of _equivalence testing_<br>
>> >> though, a BTree is not a Dictionary.<br>
>> >><br>
>> >> So as long as we interpret the various #isSomeType methods as truly of<br>
>> >> *that type* (same semantics as isKindOf:), and not "similar to", then<br>
>> >> I can see no side-effects (unless someone added #isDictionary to<br>
>> >> BTree, of course). However, we may want to visit the other #=<br>
>> >> implementations elsewhere in the system too, unless this would appear<br>
>> >> to be an inconsistency producing its own odor of sorts.<br>
>> ><br>
>> > "similar to" is vague. I *don't* interpret isFoo methods as isKindOf:<br>
>> > (and<br>
>> > think that most experienced Smalltalk programmers don't either).<br>
>> > In<br>
>> > Smalltalk type = protocol. So these methods imply that an object<br>
>> > implements<br>
>> > a given set of messages, not that they are of any given class.<br>
>><br>
>> Then I am very interested to know your thoughts about my BTree<br>
>> question, above, which shares the same protocol as Dictionary. Should<br>
>><br>
>> (BTree new at: 3 put: 'three'; yourself) = (Dictionary new at: 3<br>
>> put: 'three'; yourself)<br>
>><br>
>> return true? Why or why not?<br>
><br>
> Duck typing applies here, if it quacks like a duck. So if your BTree<br>
> behaves like a Dictionary to the extent that e.g. MethodDictionary does<br>
> (MethodDictionary supports associationAt: but isn't answering an association<br>
> within it cuz it does't contain associations) then sure, it's a Dictionary.<br>
<br>
</div></div>I do not wish to be argumentative, but does a WeakArray quack like an<br>
Array? Not only does WeakArray share exactly the same API, but even<br>
inherits from Array and "is-a" Array. So why shouldn't this be true?<br>
<br>
(Array with: 1 with: 2 with: 3) = (WeakArray with: 1 with: 2 with:<br>
3) "false"<br></blockquote><div><br></div><div>IMO that's a bug. And the bug is that WeakArray species = WeakArray, whereas it should be Array. If one selects/rejects/copies a WeakArray the result is more useful if it is strong. It would be interesting to make the change and see what effect it has on the standard test suite.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the answer is because #= (not any other method, just #=) needs<br>
to care about which _implementation_ of the argument which is passed<br>
when considering true equivalence to another object.<br></blockquote><div><br></div><div>IMO the problem is because coming up with general purpose #= implementations is hard. You must have seen the controversy my definition of CompiledMethod>>#= has caused over recent years. #= has evolved a lot since Smalltalk-80 as its been more affordable to be cleverer, but that evolution also shows that its not absolutely obvious what #= should do; it depends on context, and current definitions of #= are general agreements of useful behaviour, some of these agreements having been made a long time ago.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree we human developers can consider unequal but same-quacking<br>
objects interchangeable in our fuzzy minds when we design our<br>
applications, and that is powerful, however, *within the system*, I<br>
just it needs #= to make implementation-specific distinctions,<br>
especially for as base-classes as Array and Dictionary.<br></blockquote><div><br></div><div>One thing #= should do is accept any object as an argument without error. This wasn't always the case, but Smalltalk was not and never will be perfect. Apart from that, what #= means is something we have to negotiate. I don't think my recent changes broke anything.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This seems to be reflected by most of the #= implementations in the<br>
system, which check either #class, #species, or #isKindOf:.<br></blockquote><div><br></div><div>Few of them use isKindOf:. Some use class or species. Some use #isFoo. I don't see that #isFoo is worse than #class or #species. Do you think it is?</div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>