Thanks Lou.
In addition to what Jordan and Dmitri have said, I think part of the
> confusion is that you are assuming hash values are implicitly used in an
> equality check. They are not. They are used when your instances are added
> to certain types of collections.
You are very nice. But I was not assuming hash values were implicitly used
in an equality check. In fact, my problem was solved on the third email of
mine in this thread.
Here is the history of the question and the answer.
1. On the point of "Can we `override var hashValue`", I was and am on the
side of definitely "Yes". And Jordan Rose, was on the side of perhaps, "but
someone should carefully implemented the `hashValue` on base class and
subclasses, so that the rule "if `a==b`, then `a.hashValue==b.hashValue`
wouldn't be violated".
2. At the beginning, I still thought we could `override var hashValue`. But
it violated the rule with comparing between instances from different
subclasses. My explanation was that since the hashValue on the base class
was not violated the rule, the rule was not broken. Also I insisted that
thought it was not documented, the base of equality should be the types of
instances equaled at first. I knew my point was weak, so I asked in this
thread to see if there was something I missed.
3. I got the reply from Michael Nisi. But I thought his point was alike
Jordan's. I knew I was gotten the point of " the base of equality should be
the types of instances equaled at first" from somewhere. So I looked up.
Turned out I found it in the book "Core Java".
4. The conclusion: The rule should not be violated at any time. My previous
explanation of "since the hashValue on the base class was not violated the
rule, the rule was not broken" was wrong. However, Jordan's point "someone
should carefully implemented the `hashValue` on base class and subclass, so
that the rule "if `a==b`, then `a.hashValue==b.hashValue` wouldn't be
violated. " was also not correct. As there was no way to `override
hashValue` like that.
Here are my points on " Can we `override var hashValue`":
1. We can. But we should firstly test the `type(of:lhs) == type(of:rhs)`.
If that doesn't equal, we return false. This technique solved the problem
of mine in this thread. This should be the first choice of all situations.
2. We can but we may prefer not to. If we choose not to, we must keep that
to all subclasses of the base class. I don't prefer this way, but someone
may like it. I think doing this may gain more problems than it solves. But
again, since it does not violate any documented rules, it could exist.
3. In both 1 and 2, we must also write `==` for each subclasses.
Zhaoxin
On Wed, Sep 7, 2016 at 5:55 AM, Lou Zell <lzel...@gmail.com> wrote:
> My question is, apple equals banana, but their hashValues (in their own
>> types) don't. What's wrong here?
>
>
> Hi Zhao. In addition to what Jordan and Dmitri have said, I think part of
> the confusion is that you are assuming hash values are implicitly used in
> an equality check. They are not. They are used when your instances are
> added to certain types of collections.
>
> In your first example, where you print out the hash values but then
> compare lhs.name to rhs.name, the names of the two fruits are both
> "common fruit", and the equality test returns true. Hash never comes into
> play. You can test for yourself when the hash gets used:
>
> import Foundation
> class Foo: NSObject {
> override var hash: Int {
> print("Computing hash value!")
> return 1
> }
> }
> var f1 = Foo()
> var f2 = Foo()
> f1 == f2 // Doesn't print anything!
> var aSet = Set<Foo>()
> aSet.insert(f1) // Prints "Computing has value!"
>
> Lou
>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
