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

Igor Stasenko siguctua at gmail.com
Thu Nov 12 06:15:47 UTC 2009


2009/11/12 Andreas Raab <andreas.raab at gmx.de>:
> 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.
>

Why its not worthwhile? I think instead it worthwhile to have a
collections safe from
such recursive problems, so developers won't need to look for
workarounds in order to prevent recursion.

Because:

s := Set new.
badThing := Array with: s.
s add: badThing; add: badThing.

shows that problem is not with Sets per se, but with #hash
implementation for all collections.
Now imagine that developer could not always in direct control where
such badThing's come from, and hence he's always under the risk of
blowing up the image because of running away recursion.
I think this issue alone is worthwhile and needed to be fixed aside
the current discussion topic.

> 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).
>

but why sit and wait for these problems lurking in the dark to strike
us suddenly?
Its more philosophical problem i think, an approaches we not sharing.
I could declare any piece of code 'its good enough for use by me'. But
does that means that its good enough for use by others?
Does that means that we should stop thinking how to remove the
obstacles and limitation and make better, future-proof
implementation, once its 'good enough' especially when we are talking
about collections - one of the most widely used objects in system?


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

Sure thing. When tires meet the road.
Lets run benchmarks (know any good bench suite for sets?) and see the
difference.

> Cheers,
>  - Andreas
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list