> But we now have a lot more proposals, let me summarize them all:
> 
> - (1)add a new instance variable: containsNil
> - (2)use tally to indicate if nil is in the set
>  - (a)negative values mean nil is contained by the set
>  - (b)floats - (3)use a marker object
>  - (a)self
>  - (b)a unique object in each set
>  - (c)a class variable
> - (4)use container objects in occupied slots, like associations in 
> dictionaries
> 
> I prefer 3c, 2a, 3a, 1, 4 in the given order.
> What about you?
> 
...
 >
 > I'd prefer (3d): make a class called UnoccupiedSlot ...
 >

3c or 3d. All solutions that add inst vars or even container objects 
mean a bad tradeoff in my opinion - wasting tons of space in exchange 
for a special case that obviously wasn't absolutely necessary for all 
the years.

The question is not only how much a standard image would be inflated, 
because there are applications (thinkable) with many small sets and 
Squeak should be as universally usable as possible.

If nil can be excluded from sets system-wide, the same thing should be 
possible with a class variable or a specific class that has a much more 
specific meaning and usage than nil.

Unless the above turns out to be wrong, using a specific marker object 
is the most straightforward thing to do. Using nil for that marker 
object is sort of a hack itself and treating nil specially makes (1) and 
(2) not better.

Regards,
Martin