About getting HashedCollection (another dream happening)

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 <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________

Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2010/4/12 Peter Hugosson-Miller <[hidden email]>:

>
>
> On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko <[hidden email]> 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 <[hidden email]> 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
>> >> [hidden email]
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >>
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> 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

in squeak before adding sets-with-nils you won't see such code ,
because this will throw an error.
And so, nobody used it in that way before.
I mean, there is no code in old squeak codebase which putting nils
into sets intentionally.
So, either you intentionally puting nils there - and its completely OK,
or you intentionally do not putting them (as all old code does) -
which is also , completely OK.

>  => #(1 2 3 4 6 7)
> I'm not deciding one way or the other which way is right, just adding an
> observation.
> --
> Cheers,
> Peter
>

> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project