Torge Husfeldt Torge.Husfeldt@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.
On 30.08.2002, Richard A. O'Keefe wrote:
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.
Well, *I* think it's a reasonable request. The #pvtXXX support is in the image anyway, this submission enhances it (I think), and it comes down to a choice of style you choose to code in. As long as you don't request the system to be rewritten, or that #perform: and friends should also check it... ;-)
So, herewith is LessPvt.3.cs, this time with a preamble (but still no checking for "Am I compiling in a metaclass context?" -- do we really need that safety net?):
---snip--- Widens the Compiler's special handling of #pvtXXX selectors, to allow the following usage patterns in class methods:
self new pvtXXX (self new: n) pvtXXX super new pvtXXX (super new: n) pvtXXX
Previously, the Compiler allowed #pvtXXX method sends in instance methods only. ---snip---
Flame away :-)
Cheers, Helge
squeak-dev@lists.squeakfoundation.org