Re: [Pharo-project] About getting HashedCollection (another dream happening)
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.duca...@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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
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.duca...@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___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 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 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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
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 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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
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. --
Re: [Pharo-project] About getting HashedCollection (another dream happening)
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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On 12 April 2010 00:29, Stéphane Ducasse stephane.duca...@inria.fr 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? HashedCollection is more important/basic refactoring than nils in sets. So, adopt them first. Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente 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 ___ 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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Sun, 11 Apr 2010, Stéphane Ducasse 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? I think it's easier to add HashedCollection first, then the nil support for Set, because this way you can be sure that the changes added to Set (for the nil support) won't affect Dictionary. Levente Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente 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 ___ 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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Ok I will do that. Stef On Apr 11, 2010, at 11:39 PM, Igor Stasenko wrote: On 12 April 2010 00:29, Stéphane Ducasse stephane.duca...@inria.fr 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? HashedCollection is more important/basic refactoring than nils in sets. So, adopt them first. Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente 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 ___ 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Yes! So I will follow your steps as soon as I have a bit of time. Stef On Apr 11, 2010, at 11:48 PM, Levente Uzonyi wrote: On Sun, 11 Apr 2010, Stéphane Ducasse 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? I think it's easier to add HashedCollection first, then the nil support for Set, because this way you can be sure that the changes added to Set (for the nil support) won't affect Dictionary. Levente Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente 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 ___ 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On 03/14/10 06:22, Stéphane Ducasse wrote: thanks. I'm waiting for the hash fixes that martin and andres are looking at. OK, you've jostled me into once more actively trying to integrate the hash changes into current 1.1... hopefully I'll be able to push to the inbox soon. It will help greatly if no other changes are integrated in the meantime, though. The code changes aren't large, but this is one of those cases where changing the running system from within gets tricky. -Martin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Hi martin ok tell us what is good for you and we freeze and give you access for your changes :) When. Which version do you want to stay stable? I know that marcus is integrated my changes (of yesterday) now. Stef On Mar 18, 2010, at 7:23 PM, Martin McClure wrote: On 03/14/10 06:22, Stéphane Ducasse wrote: thanks. I'm waiting for the hash fixes that martin and andres are looking at. OK, you've jostled me into once more actively trying to integrate the hash changes into current 1.1... hopefully I'll be able to push to the inbox soon. It will help greatly if no other changes are integrated in the meantime, though. The code changes aren't large, but this is one of those cases where changing the running system from within gets tricky. -Martin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On 03/18/10 11:30, Stéphane Ducasse wrote: Hi martin ok tell us what is good for you and we freeze and give you access for your changes :) When. Which version do you want to stay stable? I know that marcus is integrated my changes (of yesterday) now. I should have been more clear -- what I want to stay stable is the hashed collection code (primarily Set and subclasses) in PharoCore 1.1. Other changes are OK, though other changes to Kernel might make the merge more interesting. I'm running a system update right now to get to the current. -Martin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About getting HashedCollection (another dream happening)
Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
2010/3/14 stephane ducasse stephane.duca...@free.fr: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Very good idea. Can't help you much, Levente did all the hard work. Remember you also have: http://code.google.com/p/pharo/issues/detail?id=213 http://code.google.com/p/pharo/issues/detail?id=902 http://code.google.com/p/pharo/issues/detail?id=1868 http://code.google.com/p/pharo/issues/detail?id=1907 ... and good tricks from Andres Valloud that Levente probably used to. Cheers Nicolas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
thanks. I'm waiting for the hash fixes that martin and andres are looking at. Stef On Mar 14, 2010, at 2:10 PM, Nicolas Cellier wrote: 2010/3/14 stephane ducasse stephane.duca...@free.fr: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Very good idea. Can't help you much, Levente did all the hard work. Remember you also have: http://code.google.com/p/pharo/issues/detail?id=213 http://code.google.com/p/pharo/issues/detail?id=902 http://code.google.com/p/pharo/issues/detail?id=1868 http://code.google.com/p/pharo/issues/detail?id=1907 ... and good tricks from Andres Valloud that Levente probably used to. Cheers Nicolas ___ 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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente 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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Yes I waiting. But thanks for the step list because this is half of the work (I hope ;)) Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
