On 12.11.2009, at 11:35, Bert Freudenberg wrote:

> 
> On 12.11.2009, at 09:42, Andreas Raab wrote:
> 
>> Levente Uzonyi wrote:
>>> 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?
>> 
>> Nice summary. My current preferences would be (1) (clear and obvious) (3b) (ditto) and (3a)/(3c) (both with some hesitation). I'm not sure about (4) (I've only just heard of it; it sounds cool but I haven't seen no code yet). I would veto both (2a) and (2b) as obscure hacks compared to (1) unless the size overhead is significant.
> 
> I'd prefer (3d): make a class called UnoccupiedSlot, use it as marker (either the class itself [I'd like that] or its singleton instance [for the purists]). This would make it blatantly obvious what's happening when inspecting the innards of a Set.
> 
> I'd reluctantly accept (1) but fear it would complicate the logic - containsNil checks will have to be scattered all over the place.
> 
> - Bert -

Thinking about migrating (possibly) old data - how do the options fare with respect to reloading serialized Sets? I guess we could count nils and detect a mismatch with tally?

- Bert -