<div dir="ltr"><div><div><div><div>As a side note, sometimes I'd like to relax =.<br></div>For example (1 to: 3) = #( 1 2 3) is a problem<br></div>- it either violate the hash equality or prevent an efficient hash computation for Intervals<br></div>- it violates transitivity of = - indeed (3 to: 2) and (5 to: 4) are not equal because they are (historically) used for marking different cursor positions in a Text, but they both equal #()<br><br></div>They behave similarly enough to be easily exchanged, so we might express this with hasSameElements or isSameSequence but not necessarily =, = is too strong IMO.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-05 3:38 GMT+01:00 Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> IMO that's a bug. And the bug is that WeakArray species = WeakArray,<br>
> whereas it should be Array. If one selects/rejects/copies a WeakArray the<br>
> result is more useful if it is strong. It would be interesting to make the<br>
> change and see what effect it has on the standard test suite.<br>
<br>
</span>Indeed..<br>
<span class=""><br>
>> 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>
><br>
> IMO the problem is because coming up with general purpose #= implementations<br>
> is hard. You must have seen the controversy my definition of<br>
> CompiledMethod>>#= has caused over recent years. #= has evolved a lot since<br>
> Smalltalk-80 as its been more affordable to be cleverer, but that evolution<br>
> also shows that its not absolutely obvious what #= should do; it depends on<br>
> context, and current definitions of #= are general agreements of useful<br>
> behaviour, some of these agreements having been made a long time ago.<br>
<br>
</span>Being cleverer in #= feels right but general agreements also feels<br>
right in terms of having dependable contracts. For example, its<br>
really nice that everyone has "agreed" to include a valid #hash method<br>
when they write an #= method. We just do it regardless whether we<br>
actually think we will put them in a HashedCollection.<br>
<span class=""><br>
>> 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>
><br>
> One thing #= should do is accept any object as an argument without error.<br>
<br>
</span>Another very good general agreement for equivalence testing. I agree! :)<br>
<span class=""><br>
> This wasn't always the case, but Smalltalk was not and never will be<br>
> perfect. Apart from that, what #= means is something we have to negotiate.<br>
> I don't think my recent changes broke anything.<br>
<br>
</span>I don't think anything will be broken. None of my outboard<br>
SpecialDictionary's implement isDictionary. It gave me pause to<br>
wonder what it should answer..<br>
<span class=""><br>
>> This seems to be reflected by most of the #= implementations in the<br>
>> system, which check either #class, #species, or #isKindOf:.<br>
><br>
> Few of them use isKindOf:. Some use class or species. Some use #isFoo. I<br>
> don't see that #isFoo is worse than #class or #species. Do you think it is?<br>
<br>
</span>Hm. In any other method besides #=, #isFoo is always better. In<br>
Dictionary>>#=, it will perform better, it probably won't break<br>
anything even external. So, definitely not worse. :) Just making<br>
sure when changing such a method as Dictionary>>#=...<br>
<span class="HOEnZb"><font color="#888888"><br>
- Chris<br>
<br>
</font></span></blockquote></div><br></div>