2009/7/3 Henrik Johansen <henrik.s.johansen@veloxit.no>:
Having collections that do not naively implement addAll: falls into that category I think. Just in case it isn't clear by now: It WILL break compatability with custom subclasses though. (which is why I think VW and Squeak will never do it)
Personally, I feel the ANSI standard failed in this regard, specifying a behaviour for addAll: that automatically leads to implementing it the naive way. Instead of say, adding all the objects that you are able to add from the collection, then raising an error with the ones you could not Especially when using addAll: with an unordered collection as parameter, it leads to random results as to what is added and what is not before the error is raised...
I agree with Ralph on the nil issue (and the implementation details if we do make one ;) ), slowing down 99.99999% of hashable collections to satisfy those few use-cases where there's a need for Sets which accept nil isn't really a super option...
I am also think that (re)placing the nil-handling code in Set itself not worth it. That's why i made it as a separate class named GenericSet.
Cheers, Henry
On Jul 3, 2009, at 11:47 26AM, Stéphane Ducasse wrote:
Our goal is to build an agile Smalltalk with faster, better.... code.
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
-- Best regards, Igor Stasenko AKA sig.