<x-rich>I think the idea can be generalized:


Testing for inclusion is part of the basic collection semantics that I

think was not completely exploited (i.e. was not made general enough),

leading to complications in the Collection class hierarchy.


We could add an instance variable called comparator to the base
Collection

class. This would be an instance of a Comparator class.


Comparator is an abstract class defining two methods: #is:eq: and

#is:notEq:, but not providing any implementation.


Comparator has three system defined subclasses:

 
<underline><color><param>ffff,0000,0000</param>EqualComparator</color></underline>
providing the implementations:

	is: <underline><color><param>ffff,0000,0000</param>leftObject</color></underline> eq: <underline><color><param>ffff,0000,0000</param>rightObject

</color></underline>	  <underline><color><param>ffff,0000,0000</param>^leftObject</color></underline> = <underline><color><param>ffff,0000,0000</param>rightObject

</color></underline>    and

	is: <underline><color><param>ffff,0000,0000</param>leftObject</color></underline> notEq: <underline><color><param>ffff,0000,0000</param>rightObject

</color></underline>	  <underline><color><param>ffff,0000,0000</param>^leftObject</color></underline> ~= <underline><color><param>ffff,0000,0000</param>rightObject

</color></underline>

  <underline><color><param>ffff,0000,0000</param>IdentityComparator</color></underline>...

and

  <underline><color><param>ffff,0000,0000</param>ArithmeticComparator</color></underline> which is an abstract class again, adding two

	method definitions: #is:lte: and #is:lt:


    Two concrete subclasses would be:

	<underline><color><param>ffff,0000,0000</param>HashComparator</color></underline> with:

		is: <underline><color><param>ffff,0000,0000</param>leftObject</color></underline> eq: <underline><color><param>ffff,0000,0000</param>rightObject

</color></underline>		  <underline><color><param>ffff,0000,0000</param>^leftObject</color></underline> hash == <underline><color><param>ffff,0000,0000</param>rightObject</color></underline> hash

		...

	<underline><color><param>ffff,0000,0000</param>BasicHashComparator

</color></underline>    .<underline><color><param>ffff,0000,0000</param>.with</color></underline> the obvious implementations



While this adds a level of indirection, it also adds more flexibility.

The above mentioned Comparator classes would provide convenient defaults,

while letting the developer "<underline><color><param>ffff,0000,0000</param>parametrize</color></underline>" the Collection classes with her

own user-defined Comparator classes.

Also, by putting under the same roof the implementations of #is:lt: and

#is:eq: (which need to be consistent) one can efficiently test for inclusion

in sorted collections by taking advantage of the sorting, and while keeping

things general (You cannot do this with a single <underline><color><param>ffff,0000,0000</param>compareBlock</color></underline>).


Any thoughts ?



Florin


</x-rich>