2009/11/13 Russell N Hyer <hrothgar.ofstingan at gmail.com>:
> still no one came up with any good reason to allow nils into sets.
>

if we'd live in ancient ages, we would argue that there is no good
reason to have
Zero in algebra & arithmetics.
http://en.wikipedia.org/wiki/Zero
[quote]
Records show that the ancient Greeks seemed unsure about the status of
zero as a number. They asked themselves, "How can nothing be
something?", leading to philosophical and, by the Medieval period,
religious arguments about the nature and existence of zero and the
vacuum. The paradoxes of Zeno of Elea depend in large part on the
uncertain interpretation of zero.
[/quote]

but since we live in modern ages, i think it will be a pointless
discussion right now.

Concerning smalltalk.
a) Everything is an object
b) Collection comment says: I am the abstract superclass of all
classes that represent a group of elements.
c) Set comment says: I represent a set of objects without duplicates.
I can hold anything that responds to
#hash and #=, except for nil.

don't you see a missing element here, between b) and c) which is:
represent a set of objects without duplicates. period?

> As I said it sounds like much ado about nulls a la :
>
> dbdebunk.com
>
> viz:
>
> http://www.dbdebunk.com/page/page/2928212.htm
>
> or
>
> http://www.dbdebunk.com/page/page/3317151.htm
>
> Like I say, I still have no reall idea why people have this desire to
> perform hacks based on nulls
>
> /me vomits in a corner based on a null or ten million
>
> 2009/11/12, Ralph Boland <rpboland at gmail.com>:
>> I appreciate that being able to add nil to a Set is useful.
>> All the discussion so far seems to be based upon how to
>> implement such a change efficiently and safely.
>>
>> I would like to point out that there is a negative to allowing
>> nil to be added to a set and as it happens it applies to
>> every instance of Set I have ever used (at least directly).
>>
>> A common bug in programs is to have an object set to nil
>> when the programmer believes the object cannot have value nil,
>> for example when the programmer has forgotten to initialize a variable.
>>
>> Currently, if such an object is added to a set an error will occur.  The
>> programmer must then from this point determine why the object
>> has value nil.  If sets are modified as proposed no error will
>> occur!!!!!!!!!!!
>> Since there is a bug, someday the programmer will discover there is
>> a problem and after some debugging effort determine that the set contains
>> the element nil (and hopefully recognize that it shouldn't).  (S)he must
>> then track down the point that nil was added to the set and thus what object
>> unexpectedly has the value nil.  (S)he then is exactly where s(he) would
>> have
>> been right away if Sets report an error on addition of nil.
>>
>> Assuming that nearly all uses of Set do not expect nil to be a possible
>> entry,
>> I propose the following:
>>
>> 1)  Add Set method  addUnlessNil: object.
>> This method does nothing quietly if  object == nil.  Otherwise it does
>>  add: object.
>>
>> 2) Add Set method  addEvenNil: object.
>>  This method adds nil to the set in some convoluted way that allows
>> nil to be used
>>  for the unused entries in the set.
>>
>> 3) Add any supporting methods such as  includesNil  and removeNil  that
>> might
>>     be needed.
>>
>> This proposal is of course UGLY for applications needing to add nil to sets.
>> For example, if one wants to add a collection to a  set then one now needs
>> methods  addAllEvenNil:  and  addallUnlessNil:.
>> It does have the following advantages though.
>>   a) It is totally backwards compatible.
>>   b) There is no performance penalty except when adding nil to a set.
>>   c) Situations where nil may be added to a set are clearly marked.
>>
>> Of course my proposal rests on the assumption that
>> nearly all uses of Set do not expect nil to be a possible entry.
>> I believe this to be true.
>> Even if my proposal is not accepted the assumption implies that whatever
>> choice is made should be efficient so as not to penalize all the
>> applications
>> that do not add nil to sets.
>>
>> An interesting side note is that one could argue that my proposal should
>> apply
>> to collections in general.  Regardless of how convinced of this one is
>> however,
>> the fact remains that such a change would break a  LOT OF CODE
>> (including some of mine) and thus be very difficult to implement in
>> practice.
>> Regards,
>>
>> Ralph Boland
>>
>> --
>> Volume * Density = Mass.
>> Volume / Density = Intelligence.
>> The latter equation explains the
>> essentially equal intelligence of men and woman
>> and the capabilities of some commonly used operating systems.
>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.