On Thu, 12 Nov 2009, Bert Freudenberg wrote:

>
> On 12.11.2009, at 13:05, Levente Uzonyi wrote:
>
>> Hi!
>>
>> On Thu, 12 Nov 2009, 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.
>>>
>>
>> What about this?
>> (3e): make a class called UnoccupiedSlot with a single instance. Add EmptyFlag to Set, and make sure that EmptyFlag is the instance of UnoccupiedSlot.
>> This way the inspector would print "an UnoccupiedSlot" for empty slots and we could save a message send in the implementation.
>
> Which message send would you save in
>
> 	... == UnoccupiedSlot
>

UnoccupiedSlot instance.
I wouldn't use a class, because I think we should be able create a set 
with any classes in it.

Levente

> ?
>
> - Bert -
>
>
>
>