Hi,
I redefined #= and #hash in one of my classes. Objects from this class are mutable and the hash value change when this objects change. It seems wrong to store mutable objects like this in a set but I can't find any documentation about this anywhere. Because when you add such an object into one Set and change the object, then the set won't find your object using #includes: anymore. What is allowed and what is not please ? Thank you |
You could use an IdentitySet instead!
On 8/15/06, Damien Cassou <[hidden email]> wrote: Hi, |
In reply to this post by Damien Cassou-3-2
Damien Cassou wrote: > Hi, > > I redefined #= and #hash in one of my classes. Objects from this class > are mutable and the hash value change when this objects change. It > seems wrong to store mutable objects like this in a set but I can't > find any documentation about this anywhere. Because when you add such > an object into one Set and change the object, then the set won't find > your object using #includes: anymore. > > What is allowed and what is not please ? Dictionary or related object which uses the hash will usually lose that object in the collection. It would be nice to have a type of object which self-corrects when this occurs -- Gemstone does that kind of thing with its indexed collections. I had not thought of this before -- I have never run into the need for it, most of my Sets and Dictionary's are of the "Identity" type -- don't know how many people run into this??? > > > Thank you > -- Dennis Smith [hidden email] Cherniak Software Development Corporation +1 905.771.7011 400-10 Commerce Valley Dr E Fax: +1 905.771.6288 Thornhill, ON Canada L3T 7N7 http://www.CherniakSoftware.com |
In reply to this post by Ricardo Birmann
Or arrange that whenever an element changes enough to affect its hash
value, a notification results in an update of the set: set add: (set remove: element) or: set rehash Or, instead of holding the objects in a straight set, use a dictionary to reference the objects whose keys do not change their hash values when the objects hash values change. Dave Ricardo Birmann wrote: > You could use an IdentitySet instead! > > On 8/15/06, *Damien Cassou* <[hidden email] <mailto:[hidden email]>> wrote: > > Hi, > > I redefined #= and #hash in one of my classes. Objects from this class > are mutable and the hash value change when this objects change. It > seems wrong to store mutable objects like this in a set but I can't > find any documentation about this anywhere. Because when you add such an > object into one Set and change the object, then the set won't find your > object using #includes: anymore. > > What is allowed and what is not please ? > > > Thank you > > |
In reply to this post by Dennis smith-4
Dennis Smith wrote:
[..] > collections. I had not thought of this before -- I have never run into > the need for it, most of my Sets and Dictionary's are of the "Identity" > type -- don't know how many people run into this??? I have yet to experience this with Smalltalk, but I helped debugging two Java applications where this occurred. The first time took ages to find the bug. The second time was somewhat easier due to the experience I had with the first time, but still it took its time :-) Cheers, Hubert -- Hubert Baumeister Associate Professor mailto:[hidden email] http://www.imm.dtu.dk/~hub phone/skype: (+45)4525-3729 / hubert.baumeister |
In reply to this post by Ricardo Birmann
IdentitySet works exactly the same as Set, but it compares the object
useing #== instead of #=, so this wouldn't help. Karsten Ricardo Birmann schrieb: > You could use an IdentitySet instead! > > On 8/15/06, *Damien Cassou* <[hidden email] <mailto:[hidden email]>> wrote: > > Hi, > > I redefined #= and #hash in one of my classes. Objects from this class > are mutable and the hash value change when this objects change. It > seems wrong to store mutable objects like this in a set but I can't > find any documentation about this anywhere. Because when you add such an > object into one Set and change the object, then the set won't find your > object using #includes: anymore. > > What is allowed and what is not please ? > > > Thank you > > |
sorry, just noticed, that it also uses #identityHash instead of #hash,
so it should work. Karsten Karsten schrieb: > IdentitySet works exactly the same as Set, but it compares the object > useing #== instead of #=, so this wouldn't help. > > Karsten > > > Ricardo Birmann schrieb: > > You could use an IdentitySet instead! > > > > On 8/15/06, *Damien Cassou* <[hidden email] <mailto:[hidden email]>> > wrote: > > > > Hi, > > > > I redefined #= and #hash in one of my classes. Objects from this > class > > are mutable and the hash value change when this objects change. It > > seems wrong to store mutable objects like this in a set but I can't > > find any documentation about this anywhere. Because when you add > such an > > object into one Set and change the object, then the set won't > find your > > object using #includes: anymore. > > > > What is allowed and what is not please ? > > > > > > Thank you > > > > > > > |
In reply to this post by Dave Stevenson-2
Dave Stevenson wrote:
> set add: (set remove: element) That won't work, you'll need to remove the element /before/ you alter its hash value (else it cannot be found during the #remove:) and add it again after the change. R - |
Right - you'd have to arrange an #aboutToChange notice for removal, then
add it back on #changed. Pretty hoaky. I think the best course would be to redesign the #hash algorithm so that it doesn't rely on attributes of the object that frequently change. Dave Reinout Heeck wrote: > Dave Stevenson wrote: > >> set add: (set remove: element) > > That won't work, you'll need to remove the element /before/ you alter > its hash value (else it cannot be found during the #remove:) and add it > again after the change. > > > R > - > > |
The simpler solution is usually the best option. If the object in hand changes a lot, in a way that at a certain point it might no longer be "equal" to it's previous self, Sets are just not appropriate.
I'd stick to IdentitySets. Best regards, Ricardo On 8/16/06, Dave Stevenson <[hidden email]> wrote: Right - you'd have to arrange an #aboutToChange notice for removal, then |
In reply to this post by Damien Cassou-3-2
On Aug 15, 2006, at 8:04, Damien Cassou wrote:
I'm intrigued. What is the desired behavior you want? If you have a set of A and B, but you then change B so that it equals A (i.e. B -> A`), what do you want the set to reflect? Should theSet size == 1, or still 2? IOW, to what end did you redefine = in the first place? For its use in sets? Or for use outside of that? -- Travis Griggs Objologist Time and Countertops. They both get used up way too fast. DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm |
Travis Griggs wrote:
> On Aug 15, 2006, at 8:04, Damien Cassou wrote: >> I redefined #= and #hash in one of my classes. Objects from this >> class are mutable and the hash value change when this objects change. >> It seems wrong to store mutable objects like this in a set but I >> can't find any documentation about this anywhere. Because when you >> add such an object into one Set and change the object, then the set >> won't find your object using #includes: anymore. >> >> What is allowed and what is not please ? > I'm intrigued. What is the desired behavior you want? If you have a > set of A and B, but you then change B so that it equals A (i.e. B -> > A`), what do you want the set to reflect? Should theSet size == 1, or > still 2? IOW, to what end did you redefine = in the first place? For > its use in sets? Or for use outside of that? This is the kind of question Georg Heeg point me to. I didn't think enough on what I wanted. Now, it's clearer in my mind and I modified the requirement. An IdentitySet is now perfect for what I want. Thanks to all of you for your help |
Free forum by Nabble | Edit this page |