>
>
> On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko <
siguctua@gmail.com> wrote:
>>
>> Oh.. again..
>> @Ralph: if you don't want sets with nils, just don't put them there.
>> Why this isn't obvious for you?
>> Take a Squeak , which already supporting nils in sets.
>> Have you seen ANY reported breakage of existing code because of this?
>>
>> On 12 April 2010 05:25, Levente Uzonyi <
leves@elte.hu> wrote:
>> > On Sun, 11 Apr 2010, Ralph Boland wrote:
>> >
>> >>> Hi levente/igor
>> >>
>> >>> this hashedCollection is still on my radar. Now I was wondering if I
>> >>> should > work first on Set with nil or HashedCollection.
>> >>> Any idea/suggestion?
>> >>
>> >>> Stef
>> >>
>> >> I think moving Dictionary out from under Set is a great idea.
>> >> However I am not convinced having a class HashedCollection
>> >> to share common code between Set and Dictionary is worth it.
>> >> I would just tolerate the code duplication because these classes
>> >> are so important. �Given that Squeak is going to support
>> >
>> > I don't see your point here. In Squeak that would mean duplicating 17 +
>> > 9
>> > methods (instance/class side) + the two instance variables for no
>> > reason.
>> >
>> >> HashedCollection though, I would hate to see yet another difference
>> >> between Pharo and Squeak. I expect that the difference is unlikely
>> >> to break code shared between Pharo and Squeak though.
>> >>
>> >> I was always against allowing the addition of nil to sets.
>> >> This change means that every time I accidentally add nil to a set
>> >> the error will go undetected and will be difficult to track down once
>> >> the problem is discovered.
>> >
>> > Collections are still not ment to be bug detectors... Btw, do you notice
>> > if
>> > you add nil as a key to a Dictionary? (or add nil to an
>> > OrderedCollection?)
>> >
>> >> My solution to escape this change in my code will be to subclass
>> >> Set and any of its subclasses that I use and add code in the subclasses
>> >> to test for addition of nil and report an error when it happens.
>> >> This will allow bugs to show up sooner.
>> >
>> > You can (ab)use PluggableSet if you really need this by adding the nil
>> > check
>> > to the hashBlock.
>> >
>> >> An alternative is just to modify Set itself by adding a test for
>> >> adding nil to a set and then reporting an error. �This change will
>> >> break
>> >> down of course once there are instances of actually adding nil to a set
>> >> in Squeak/Pharo.
>> >> Are there any such occurrences is Squeak 4.1?
>> >
>> > Who knows, nil can be everywhere: #(1 2 nil) asSet.
>> >
>> >> Now that this feature will be in Squeak 4.1, however, we again have
>> >> the problem of divergence of code between Pharo and Squeak. �The
>> >> problem won't be there immediately but eventually this feature
>> >> will actually be used in Squeak.
>> >> Of course the issue here is how often it is useful to allow
>> >> addition of nil to a Set. �For the approximately 100,000 lines of
>> >> code I have written in Smalltalk the answer is 0 explaining my
>> >> opposition to this change. �For some others though the answer
>> >> must be different.
>> >> For me this change will delay my moving my code from Squeak
>> >> 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)).
>> >> Note that I use Sets and Dictionaries a lot. �When my Squeak project
>> >> runs 80% of the time is spent on �Set/Dictionary operations.
>> >
>> > You could have added nil as a key to a Dictionary and that went
>> > undetected...
>> >
>> >
>> > Levente
>> >
>> >>
>> >> 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
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> Heh, well I understand Ralph's point quite well, since I know that in the
> project I'm working on there are places in the code that depend on the fact
> that sets can't contain nil. So the following would break if VisualAge added
> that possibility:
> #( 1 2 3 4 nil 6 7 nil) asSet asArray
�#( 1 2 3 4 nil 6 7 nil) asSet