radoslav hodnicak <rh at 4096.sk> wrote:
	I'm advocating for Set in squeak that can be used in the same
	nil-squashing way as in any other smalltalk dialect I've ever
	worked with.
	
Note that the ANSI Smalltalk standard says that a Set may not accept
nil elements, but it ALSO says that you CANNOT rely on it NOT accepting them.

It has always seemed quite irrational that most collections either
    - allow any kind of Object, or
    - require a specific protocol (like SortedCollection), or
    - are tied to a specific 'primitive' type (like ByteArray)
except for Sets, Bags, and Dictionaries, which allow any object that
supports #hash and #= (or #identityHash and #== for IdentitySet &c)
*except* for one specific object which DOES support those methods in
a way which is perfectly usable.

That's no way to run a railroad.

It turns out that the reason for the rejection is failure to follow
OO principles.  An implementation detail (not to say perversity) has
been allowed to show through.  The really sad thing is that it is a
detail of an implementation which is, to put it politely, not very
good.	
	
I have my own collection library now, developed for my own education,
and part of it is an implementation of Set and its relatives which
- couldn't care less about nil
- doesn't have any other sentinel either
- would have to waste extra time going out of its way to block nil.
- handles filling up rather more gracefully
(How?  See any good data structures and algorithms textbook.)

Portable code shouldn't rely on implementation-specific assumptions.
Good quality libraries should have simple descriptions with only the
exceptions that are really essential.