Nevin Pratt <nevin at smalltalkpro.com> wrote:
	The final draft of the ANSI standard (and presumably the actual 
	standard) specifies that if the argument to #add: for Set is nil, the 
	results are undefined.
	
Which tells us that code which is *intended* to be portable
should never ever EVER do this.

	VisualWorks for this case just returns nil, and otherwise does nothing.
	Squeak throws an exception.
	
There are only two reasonable things that

    s := Set new.
    s add: nil.
    s size

can do:  return 1 or produce some sort of error notification.
In Squeak 3.0 and 3.2 I get an error notification saying
    "Sets cannot meaningfully contain nil as an element"
which says it all, really.  It's about as good an outcome as one could
hope for, given the rather odd restriction that nil CAN be an element of
an Array but CAN'T be an element of a Set even though it supports all the
methods that a Set element otherwise needs...

	GLORP appears to depend upon the VisualWorks behavior.  Since GLORP has 
	been ported to VA and Dolphin, I'm guessing that they also have VW's 
	behavior.  Thus, Squeak appears to be the odd-man out.
	
Clearly GLORP needs to be fixed here.  Unless, of course, VW, VA, and Dolphin
allow nil in Sets, in which case Squeak's Set needs fixing.

	I personally am not a fan of exceptions, and use them very sparingly, if 
	at all.  And in this case, I personally prefer VW's behavior.
	
I was going to say that "there's only one word for claiming that a message
was handled when it wasn't, and that's 'outrageous'".  But then I thought of
a lot more words for such misbehaviour.

The *implementation* of Set in Squeak prohibits nil Set elements,
but it would be a very minor change to the code to allow them.
(Add a class variable, lazily initialise it to Object new, use that as
the 'sentinel' value instead of nil.)  I appreciate that nil is the
unique object of class UndefinedObject, so there is some sense to keeping
nil out of collections, but Smalltalk doesn't consistently keep nil out
of ALL collections.