2009/7/3 Reinout Heeck <reinz@desk.org>:
On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote:
Since I am here allow me to state my opinion on the matter. We should not add the ability to add nil to Sets. Â While I admit I don't know for sure, I believe the number of instances where we need to add nil to a set is rare.
I am of the opposite opinion (and quite strongly so :-)
When writing code that uses sets I don't want to be bothered with the need to think about special cases (like nil). I agree that the number of instances where it *actually* happens is small but it does force authors to think of it *every* time they write code that adds objects to sets -- particularly hard to keep up when those objects are handed in from yet another module not under their control.
Smalltalk being about abstractions and Pharo being about raising squeak to a 'professional' level I think it is very important to isolate the Pharo programmer from such library implementation idiosyncrasies -- they should be allowed to write abstract (naive if you will) code without fear that it breaks on such special cases.
 For the rare cases in which it is needed we should create a class  SetSupportingNils which has two instance variables:   containsNil:  a boolean set to true iff  the SetSupportingNils   instance contains nil.
IMO such a set should be named 'Set' and the one that optimizes for not holding nil should be the one that is given a special name.
As a critique of the proposed implementation: If you put the sentinel in the newly introduced ivar (instead of a boolean) the implementation will be simplified (all nil checks become checks against the sentinel as opposed to introducing 'case statements' in most of its implementation).
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.
Issue:   I suppose we need a  BagSupportingNils class too.
Yes, and it should be named 'Bag' ;-)
Now there clearly are costs associated with doing this:
Set instantiation requires overwriting nils put there by the VM, this could be mitigated in the future by adding object instantiation protocol that is handed the sentinel. Perhaps in the short run this can be decoupled from the VM by using a plugin -- but I don't know if a plugin is allowed to take over object allocation.
Custom set subclasses will break (but only if they explicitly check for nilled slots) -- but this seems like a mostly fail-fast scenario to me so it requires a code maintenance investment that seems mostly limited to a one-off cost. Anyway, finding all subclasses of Set doesn't seem too hard to me ;-)
In short: Set is cheating and it is doing it poorly, it gets caught when code happens to stuff a very public object called nil in it. It should be taught to cheat better so it doesn't pollute code at other levels of abstraction with special cases.
And yes: this requires an investment...
Thanks for supporting my point , Reinout . For those who is not aware, i wrote a GenericSet class, and it is showing the difference (how much more complex it comparing to current Set). I can also modify a code which avoids using extra instance var. Simply by encoding presence of nil in the 'tail' ivar: 0 or positive - nil is not included negative - nil is included
R -
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.