Torge Husfeldt <Torge.Husfeldt at gmx.de> wrote:
	[You _can_ use soft private initialisers without letting anyone
	 use them to smash existing objects if you make them check that
	 the object hasn't been initialised yet.]

Thank you very much for this suggestion.
While I don't like "cluttering up" my code with such tests,
there isn't any efficiency argument against this because
such a test happens only once in the lifetime of an object.
(All going well.)  I must remember this technique.

	n this case the invariant "keys are never nil" might do.

Ah.  Time to come out into the open.  There are two things that I am
not happy with about Set and Dictionary.
(1) In some of my tests, removing a bunch of elements from a Set seems
    to be rather slow.  Make that "extremely slow".
(2) The fact that you cannot put nil in a Set or use it as a key in
    Dictionary smells to me more like a quirk of the implementation
    (which uses 'nil' in slots to indicate that they are empty) than
    something motivated by considerations of what people might want
    to *do* with a Set or Dictionary.  For example, you might want
    to eliminate duplicates from a collection, so you do
	aCollection := aCollection asSet asArray.
    But that doesn't work if nil could be in aCollection.  And yes,
    I have wanted to do that.

So I've made my own "NewSet" class (so as not to change an existing class)
and "NewDictionary" is in the works.  As far as I'm concerned, keys MAY be
nil.  #includes: and #remove:ifAbsent: are pleasantly faster in NewSet
than in Set; #add: is about the same (it allocates a new object, which
Set>>#add: does not).

	Otherwise you might have to invent a new instance variable.

While an "already initialized?" test happens only once in the lifetime
of an object, an extra slot takes up space all the time.

I guess if I propose a change to existing things I'll be howled down again,
but it _would_ be nice if the compiler accepted
	(<self | super> <new | new:...>) pvtMessage...
in a class.