On Mon, Apr 12, 2010 at 2:06 PM, Igor Stasenko <siguc...@gmail.com> wrote:
> 2010/4/12 Peter Hugosson-Miller <oldmanl...@gmail.com>: > > > > > > On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko <siguc...@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 <le...@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 > 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 > > 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 > Sig, I agree with you! My example was of some code that would not survive the transition: using a asSet as a cheap way to get rid of the *possible* nils in a collection. In fact, I think I'm going to take a look at our code and do something about it now, just in case... Thanks for the heads-up -- Cheers, Peter
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
