<x-rich>Travis Griggs wrote:


>The idea was to use the same pattern that
<underline><color><param>ffff,0000,0000</param>SortedCollection</color></underline>
uses by

>giving Set a two block instance variables, one a two argument block to

>compare two objects by (<underline><color><param>ffff,0000,0000</param>equivalenceBlock</color></underline>) and the other a single

>argument block (<underline><color><param>ffff,0000,0000</param>hashBlock</color></underline>) used to compute the hash value of an object.

>.......................................... Hashing is a function used

>by Sets (and their various subclasses). It has nothing to do with what

>the object does itself. How to hash an Object should be bound to a Set.

>And not necessarily a subclass type of Set, but the instance itself. If

>we used blocks, then we wouldn't have to have <underline><color><param>ffff,0000,0000</param>IdentitySet</color></underline> and Set (along

>with the various subclasses of each). You would just create a Set

>initialized for either equality or identity. And you could do other

>things too.


For example I wanted in an application to redefine both #= for my persistent

objects (meaning their non-key variables were equal) and #== (meaning

their key variables were equal). I could not actually re-implement #==

(<underline><color><param>ffff,0000,0000</param>Enfin</color></underline> does not even let you try), and the reason why a new method #equals:

was not enough was precisely that I wanted to use the existent Set subclasses

as containers, without re-implementing them all as <underline><color><param>ffff,0000,0000</param>EqualsSet</color></underline>...



>I have no problem with implementing a hash method in an object for

>convenience's sake, but I think we should generalize the Set's

>themselves a bit further and put this thing to rest once and for all.


I think it's a great idea.


Cheers,


Florin


</x-rich>