Oh... I meant to see what happens in VW, where there are numerous dictionary and set classes. Moreover, every so often there's the need for e.g.: a hash bucketed set with mutex protection, such as for the symbol table. Since the base classes do not have pluggable strategies, then the special set has to be reimplemented from scratch... Stéphane Ducasse wrote:
andres
Something that could be considered down the road is restructuring the collection hierarchy to, among other things, allow pluggable hashed storage strategies for hashed collections. This approach should drastically reduce the number of classes in the hashed collection class hierarchy (c.f.: what happens in VW).
andres do you mean that this is done in VW.
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project .
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
.