Thanks ralph. I think that this is not a so good idea to have nil as element. BTW: just to make sure. Our is not to hijack people from the squeak community (because when I scanned some emails there I thought that we were considered as evil and bad guys - people have a short memory). Our goal is to build an agile Smalltalk with faster, better.... code. And to make sure that people can reinvent the future because they can use cool abstractions. Stef On Jul 3, 2009, at 8:53 AM, Ralph Boland wrote:
Please note the change of topic; adding the ability to add nil to sets won't make sets faster and may well make them slower so has nothing to to with the FasterSets package.
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. 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.
set: an instance of Set or one of its subclasses and used to store any object added to the SetSupportingNils instance except of course nil.
This means that SetSupportingNils would need to recognize any message that Sets or its subclasses can understand. Any message not understood by SetSupportingNils would be forwarded to its set instance variable. My proposal is not very efficient when adding nil to a set is needed but it requires no modifications to Set or any of its subclasses. That a rarely used class is somewhat inefficient is acceptable.
Issue: I suppose we need a BagSupportingNils class too. Are there any other classes we need? Can they be combined into one class?
Regards,
Ralph Boland
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project