[Pharo-project] keyAtValue: -> keysAtValue:
keyAtValue: returns one key of the value specified but if you have more time the same value the method return one key. An example: t:=Dictionary new. t at: 'toto' put: 4. t at: 'foo' put: 4. t keyAtValue:4. -> 'foo' So we can't recuperate all of the keys. I propose to create the methods keysAtValue: who return an Array with all the keys for this value. I'm not in Pharo very long time so I can not say if it can be useful so I am asking to you the question. Tristan Bourgois. -- View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2165484.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi, I think one question one should always ask: Do I have a real need for the new method? Sometimes it makes sense to add new API methods even outside of direct need. Consistency is the most important reason to add something. So is there a direct need for your method? Marcus On May 10, 2010, at 4:36 PM, Tristan Bourgois wrote:
keyAtValue: returns one key of the value specified but if you have more time the same value the method return one key. An example: t:=Dictionary new. t at: 'toto' put: 4. t at: 'foo' put: 4. t keyAtValue:4. -> 'foo'
So we can't recuperate all of the keys. I propose to create the methods keysAtValue: who return an Array with all the keys for this value.
I'm not in Pharo very long time so I can not say if it can be useful so I am asking to you the question.
Tristan Bourgois. -- View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2165484.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
But marcus the problem is right now keyAtValue: is bogus. Did you see it? On May 11, 2010, at 9:41 AM, Marcus Denker wrote:
Hi,
I think one question one should always ask: Do I have a real need for the new method?
Sometimes it makes sense to add new API methods even outside of direct need. Consistency is the most important reason to add something.
So is there a direct need for your method?
Marcus
On May 10, 2010, at 4:36 PM, Tristan Bourgois wrote:
keyAtValue: returns one key of the value specified but if you have more time the same value the method return one key. An example: t:=Dictionary new. t at: 'toto' put: 4. t at: 'foo' put: 4. t keyAtValue:4. -> 'foo'
So we can't recuperate all of the keys. I propose to create the methods keysAtValue: who return an Array with all the keys for this value.
I'm not in Pharo very long time so I can not say if it can be useful so I am asking to you the question.
Tristan Bourgois. -- View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2165484.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On May 11, 2010, at 10:35 AM, Stéphane Ducasse wrote:
But marcus the problem is right now keyAtValue: is bogus. Did you see it?
It does work when ypu know that there is only one value that is identical. Than you can use it to map back and forth. (slowly one of them, of course). If there are two values that are the same, the message does not make that much sense. I guess this method is used for just the cases when the client needs a table for maping in both directions. The only client in the Core image is ServerDirectory: nameForServer: aServer ^self servers keyAtValue: aServer which is only called by methods that have no senders. Maybe we should clean this a bit? Marcus
On May 11, 2010, at 9:41 AM, Marcus Denker wrote:
Hi,
I think one question one should always ask: Do I have a real need for the new method?
Sometimes it makes sense to add new API methods even outside of direct need. Consistency is the most important reason to add something.
So is there a direct need for your method?
Marcus
On May 10, 2010, at 4:36 PM, Tristan Bourgois wrote:
keyAtValue: returns one key of the value specified but if you have more time the same value the method return one key. An example: t:=Dictionary new. t at: 'toto' put: 4. t at: 'foo' put: 4. t keyAtValue:4. -> 'foo'
So we can't recuperate all of the keys. I propose to create the methods keysAtValue: who return an Array with all the keys for this value.
I'm not in Pharo very long time so I can not say if it can be useful so I am asking to you the question.
Tristan Bourgois. -- View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2165484.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ 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
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On May 11, 2010, at 11:13 AM, Marcus Denker wrote:
On May 11, 2010, at 10:35 AM, Stéphane Ducasse wrote:
But marcus the problem is right now keyAtValue: is bogus. Did you see it?
It does work when ypu know that there is only one value that is identical.
Than you can use it to map back and forth. (slowly one of them, of course).
If there are two values that are the same, the message does not make that much sense.
I guess this method is used for just the cases when the client needs a table for maping in both directions.
The only client in the Core image is ServerDirectory:
Ups. Missed Encoder>>tempNames. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
I understand what you said. But I think keyAtValue: is not pertinent. In the case where there are more than one same values, you can't know which value is selected. I should say that replace keyAtValue: by keysAtValue: because, I think, it's more pertinent. -- View this message in context: http://forum.world.st/keyAtValue-keysAtValue-tp2165484p2173574.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On May 11, 2010, at 11:20 AM, Tristan Bourgois wrote:
I understand what you said. But I think keyAtValue: is not pertinent. In the case where there are more than one same values, you can't know which value is selected.
I should say that replace keyAtValue: by keysAtValue: because, I think, it's more pertinent.
And clients that want to use the back-mapping can just do (myDict keysAtValue: 'hello') first. This would make the problem explicit. *and* they could even than add an assert to make sure that the mapping does not degenerate. I cleaned ServerDirectory a little: http://code.google.com/p/pharo/issues/detail?id=2408 So there is just Encoder left. Which will disappear in 1.2 anyway. So yes, we could do that. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
cool tristan if you have code we will integrate it in 1.2 :) Open a bug entry and put code there. Stef On May 11, 2010, at 11:28 AM, Marcus Denker wrote:
On May 11, 2010, at 11:20 AM, Tristan Bourgois wrote:
I understand what you said. But I think keyAtValue: is not pertinent. In the case where there are more than one same values, you can't know which value is selected.
I should say that replace keyAtValue: by keysAtValue: because, I think, it's more pertinent.
And clients that want to use the back-mapping can just do
(myDict keysAtValue: 'hello') first.
This would make the problem explicit. *and* they could even than add an assert to make sure that the mapping does not degenerate.
I cleaned ServerDirectory a little: http://code.google.com/p/pharo/issues/detail?id=2408
So there is just Encoder left. Which will disappear in 1.2 anyway.
So yes, we could do that.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Marcus Denker -
Stéphane Ducasse -
Tristan Bourgois