Yes, canEqual implementation also make #= be commutative. On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz@gmail.com>:
I am sorry, not species, but #isKindOf istead of #= to compare classes.
It is bad idea. #= should be transitive.
Oh, I used wrong word, shame on me :). I tried to say commutative.
How you will generate it with isKindOf: logic? You need to know common parent.
Also I not remember cases where I was needed two instances of different classes to be equal. And I can imaging the problems which it will lead to.
On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:
Two questions/comments about the generated code: 1. #= ... self class = anObject class "should compare #species instead?" ifFalse: [ ^ false ]. ... Typically, I've seen #species instead of #class in the guard statement. Should we change it to that?
I doubt that it is important for domain classes. Because I never saw the user of #species which is not a kind of Collection. And for collections this refactoring is not valid anyway.
2. #hash ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) Is this implementation always safe? It's what I usually hand roll based on what I've seen, but Andres Valloud wrote a whole (large) book on hashing, so I've always wondered if I was missing somethingâ¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html