On Sat, Sep 3, 2016 at 1:31 AM, Zhao Xin via swift-users
<[email protected]> wrote:
> func ==(lhs: Apple, rhs: Apple) -> Bool {
> return lhs.name == rhs.name && lhs.shape == rhs.shape
> }
>
> func ==(lhs: Banana, rhs: Banana) -> Bool {
> return lhs.name == rhs.name && lhs.shape == rhs.shape
> }
There is no reason to compare the shape, it is a constant in each of
these types. (So I am not sure what your point is.)
> My question is, apple equals banana, but their hashValues (in their own
> types) don't. What's wrong here? Is that means we shouldn't override
> hashValue in subclass in Swift?
This means you should not override hashValue in this particular way.
If two values are equal, their hash values should be equal. As long
as your override implementation guarantees this, you can override
hashValue.
You should also understand that the ==(Apple, Apple) and ==(Banana,
Banana) are not overrides for ==(Fruit, Fruit), and they would not be
called through dynamic dispatch when you have, for example, two apples
typed as fruits.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <[email protected]>*/
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
