2009/11/13 Levente Uzonyi <leves at elte.hu>:
> On Fri, 13 Nov 2009, Igor Stasenko wrote:
>
>> You are right, that currently developer expects to see an error if nil
>> been added to set.
>
> I doubt that anyone ever wrote error handling code around #add:. Developers
> expect that the value they add to a Set is not nil, and they don't expect to
> get an error at all.
>

Right. if developer ever considering putting and error catching blocks
around some code, it
is obvious not around #add:, because its too microscopic level.

>> But i don't agree that adding new sets could make tracking down an
>> error(s) any harder, because see, we having
>> a lot of different collection types, which allow nils from very
>> starting and i never head of anyone
>> complaining that it makes debugging any harder because of nils or any
>> other object which sits in collection(s).
>
> Sets are not ment to be used for error detection.
>
Right said! :)

>> My proposal is to make two different classes, one which allows nils,
>> other throws an error , as currently does.
>> But again, i don't wanna see references to new globals in code, like:
>> SetWithNils new
>>
>> instead, if user wants to explicitly state what kind of set he prefers
>> to use, he should do it using a message:
>>
>> [Identity]Set withoutNils new
>> or
>> [Identity]Set withNils new
>>
>> and by default
>> Set new
>>
>> should be Set withNils , so later when critical mass will emerge we
>> could see, based on how often it used,
>> if we may simply deprecate #withoutNils and remove obsolete interface
>> from system, or instead leave it as is.
>>
>
> Duplicating the number of set classes sounds like a really bad idea.

i am only proposed this to satisfy those who can't imagine having sets
containing nils.
And given that sets with no nils is specialization of more generic
set, it is logical (despite how minor difference is)
to have a separate class for that, in same way as we having Set and
IdentitySet and so on.
So, i'd rather have two classes instead of dubious additional interface in Set.

> If changing the current behavior is such a big issue (which I doubt), then we
> shouldn't change the current behavior.
>

> Levente
>
>



-- 
Best regards,
Igor Stasenko AKA sig.