[squeak-dev] Re: Ideas about sets and dictionaries

Andreas Raab andreas.raab at gmx.de
Thu Nov 12 05:35:03 UTC 2009


Igor Stasenko wrote:
> The main purpose to be able to handle nils in sets as an elements is to make Set
> be able to hold _any_ potentially existing objects in image.

Absolutely not. The main purpose of having nil be included in sets is to 
remove a particular restriction (namely that Sets cannot contain nil), 
not to "be able to hold _any_ potentially existing objects in an image". 
What is being proposed is trading one restriction (Sets cannot contain 
nil) against another one (Sets cannot contain their internal private 
marker) which is deemed advantageous as it allows us to convert many 
collections that contain nil into sets without blowing up. *That* is the 
main purpose.

The goal of "be able to hold _any_ potentially existing objects in an 
image" is neither achievable nor worthwhile. Try this for starters:

   (s := Set new) add: s; add: s.

Without having to do anything like reflection and picking arbitrary 
objects I can create an (undetected) problem that no proposal addresses. 
If you actually mean what you say above I think there are more 
problematic issues to solve (problems similar to the above have actually 
caused random lockups in the wild).

The point here is that Sets *do* have limitations and what we're trying 
to do is to be more helpful in the set of limitations that we require. 
Not being able to say "Set with: nil" is silly; not being able to say 
"(s := Set new) add: (s instVarAt: 3)" is a much more reasonable 
restriction.

BTW, even having said all of the above I'm still not fully convinced 
that Randal's proposal is the best way to go. It might be simpler to 
just have a flag that says "this set contains nil" like you were 
proposing. Whether that needs to be done by using a negative tally or 
whether it is better to just add an ivar "hasNil" is yet another question.

It would be rather more interesting to me to discuss the practical 
tradeoffs of the choosing one way (marker instead of nil) over the other 
(flag indicating nil containment) in terms of implementation and 
performance costs.

Cheers,
   - Andreas




More information about the Squeak-dev mailing list