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
>