> Am 06.03.2017 um 18:10 schrieb jtuc...@objektfabrik.de: > > Hilaire, > > as soon as the hash of an object changes because you change an attribute that > is used in the hash function, the object is not identical to its older ego > any more, so Voyage cannot know it still is the same object (nor any other > caching solution). > Or am I wrong about this whole hash/= thing? > Yes :) You are mixing equality and identity. An object is identical if the memory location is the same. An object is equal whatever is defined in =/hash. In the default case classes do not overwrite =/hash so = and == return the same value. If you change the state of an object you might change the hash but not the identityHash. So it is identical but different to the version in the database hence should update the existing object and not creating a new one.
> The only thing I could imagine is that Voyage somewhere uses = where it > should use ==. But wouldn't many more people have problems then? > The problem is that we often use equality based collections where we should use identity based ones. These problems are hidden because = and == are the same for normal classes. As soon as you overwrite =/hash you experience problems because of that. So I have the impression that in general overwriting =/hash is not a good idea. Most of the time you mean "equal regarding to some context". In this case it is better to have your own equality selector like #isSameX:, #hasSameX: etc. Because the kernel classes rely on = equality you tear the semantics apart if yoou overwrite. Norbert > Joachim > > > > Am 06.03.17 um 18:03 schrieb Hilaire: >> The more I think the more it seems wrong to me. Whenever you ask an >> instance to save itself, if already in repo it should not duplicate >> itself whenever hash/= is overrided in this object. It does not sound as >> an expected behaviour. >> >> Hilaire >> >> Le 05/03/2017 à 14:51, Hilaire a écrit : >>> Understood. >>> My use/understanding of hash and =, true in DrGeo, was more like unique >>> identifier regarding its ontological characteristics (what distinguish >>> it from other). So an exact same Point in DrGeo will have different hash >>> value depending on its position on the plane, or it being free on a >>> line, etc. May be I got it biased here. >>> >>> Anyway problem solved, comparing protocol was just rampant code. > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de > <mailto:jtuc...@objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de > <http://www.objektfabrik.de/> > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > <http://joachimtuchel.wordpress.com/> > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
