On Jul 3, 2009, at 9:53 AM, Reinout Heeck wrote:
I think that Andres' suggestion of using self as sentinel might be
hitting a very sweet spot as a tradeoff between special cases and run-
time efficiency.
The idea of using 'self' as a special flag sure seems like a special case; and while I have never created a self referential sets... it just seems like someday somebody will get burned badly discovering this implementation (as a matter of debugging their app).
As someone still on the learning curve (less than two years of smalltalk scattered over time), I have come to assume that anything storing data with "holes" in it (a/k/a sparse) will fill those holes will nil, and therefore nil is NOT an acceptable element to be stored. That said, let me add that it seems like I have to create a NullDatum (a nil'ish singleton) type object with some frequency.
I seem to remember the first axiom from modern Set Theory goes something like this: the empty set (nil) is a set (value)!
So, in principle, why not allow nil on the public interface (which could be mapped to some singleton in the implementation)? There would be no speed penalty -- in the most minimal form of always remapping nil in the public interface to NullDatum (or whatever it would be called) would be insignificant. I suppose it could break some existing code... somewhere outside the collection classes.
On the other hand, using a specialized subclass is OK too, especially given that I do not have the time to go change the all of the collection classes to make certain they are consistent in allowing nil.
-Cam