[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
|