Re: [Pharo-project] About getting HashedCollection (another dream happening)
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 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. 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. 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? 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. Regards, Ralph Boland
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
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.
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 6 7) I'm not deciding one way or the other which way is right, just adding an observation. -- Cheers, Peter
2010/4/12 Peter Hugosson-Miller <oldmanlink@gmail.com>:
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 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.
On Mon, Apr 12, 2010 at 2:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/4/12 Peter Hugosson-Miller <oldmanlink@gmail.com>:
On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko <siguctua@gmail.com>
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
wrote: +
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
On Mon, 12 Apr 2010, Peter Hugosson-Miller wrote: <snip>
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.
(ab)using asSet this way is bad practive (if it works at all in VA). #(1 2 3 4 nil 6 7 nil) reject: #isNil and #(1 2 3 4 nil 6 7 nil) select: #notNil (or the corresponding versions with block arguments) are the way to do it. Levente
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
igor peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes.... Stef
On Apr 12, 2010, at 5:33 42PM, Stéphane Ducasse wrote:
igor
peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes....
Stef
Or their application may have different expectations for what methods are ok to return collections with duplicated/nils in them. In which case (in VW) mySourcesWithoutNilsOrDuplicates |myColl| myColl := List new. myColl addAll: self aSourceWithNils. myColl addAll self aSourceWithDuplicates. ^myColl asSet might have been an entirely legit use, which is sure to cause headaches if ported to a dialect which allows nils. Not that that's a common occurrence, or something we should account for, just sayin' Cheers, Henry
Peter mentioned VA, whose Set's swallow nil's. Perhaps that's the missing link in the communication here. Igor is talking about *Squeak*, which does not swallow nil's, it throws an error. So, to "fix consequences instead of causes" in the case of Squeak, the software would have to be doing something like: [ #(1 2 3 nil) asSet ] on: Error do: [ : err | "ignore it!" ] which, deserves to break if it exists at all.. On Mon, Apr 12, 2010 at 10:33 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
igor
peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes....
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, 13 Apr 2010, Chris Muller wrote:
Peter mentioned VA, whose Set's swallow nil's. Perhaps that's the missing link in the communication here. Igor is talking about *Squeak*, which does not swallow nil's, it throws an error.
So, to "fix consequences instead of causes" in the case of Squeak, the software would have to be doing something like: [ #(1 2 3 nil) asSet ] on: Error do: [ : err | "ignore it!" ] which, deserves to break if it exists at all.. Squeak doesn't raise an error, but adds nil to the set (since 4.1), so there's no need for such tricks. If you want to ignore nils, just #reject: or #remove: them. Levente On Mon, Apr 12, 2010 at 10:33 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
igor
peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes....
Stef _______________________________________________ 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
participants (7)
-
Chris Muller -
Henrik Johansen -
Igor Stasenko -
Levente Uzonyi -
Peter Hugosson-Miller -
Ralph Boland -
Stéphane Ducasse