I share the point made by Lukas. Symbol>>value:value: is very obscure. If we introduce Symbol>>value:value:, why not Symbol>>value:value:value: and so on? Alexandre On 21 May 2009, at 04:00, Stéphane Ducasse wrote:
I would be in favor of having value: value: on symbol and get rid of value on Object Because this is really cool to write #( 1 2 3) collect: #abs
On May 20, 2009, at 4:01 PM, Tudor Girba wrote:
Hi,
(I apologize for the length of this email, but I did not know how to write it shorter)
My reasons for Symbol>>value: and similar selectors are as follows.
A Symbol is already used for several things, like a key in an identity dictionary. But it is also used for parameterizing a mapping to a piece of behavior via a #symbol stored in a selector instance variable. Later on, this behavior is invoked as:
receiver perform: selector.
This is for example what happens in Morphic, and as a result I am forced to create a Model class for a custom Morph, even if the customization is minimal. This is a hurdle when you are in prototype mode. Instead I would like to have the possibility to prototype faster using blocks instead of creating a class.
This is possible right now for unary methods when the framework does not directly do a perform:, but instead it does:
selector value: receiver.
Ideally, we could have in the entire image only one place in which perform: is called explicitly: in the Symbol>>value:. In this way, I will be able to pass a block everywhere a unary method is now used. This is something we do when we want to use Smalltalk for scripting (Mondrian and Glamour do that)
The same case goes for Symbol>>value:value: . These two methods would already cover the large majority of performs, but I would argue for adding all possibilities of evaluating blocks and of performing messages.
If you are asking what do Symbol have to do with blocks from a conceptual point of view, I will answer that when the Symbol is used as a selector, it does nothing else but point to a piece of behavior. Given that a Block does a similar thing, you can as well treat them in a polymorphic fashion.
The only question that remains in my mind is: does a modification like this has the possibility of harming? I am not aware of a case in which it is harmful, but who knows.
Cheers, Doru
On 20 May 2009, at 15:27, Stéphane Ducasse wrote:
value from Object and value: from Symbol are different with value: on Symbol you can do
self collect: #abs
:)
On May 20, 2009, at 2:48 PM, Gabriel Cotelli wrote:
+1 to the removal of value: from Symbol....
On Wed, May 20, 2009 at 3:18 AM, Lukas Renggli <renggli@gmail.com> wrote:
Given that in Pharo we have Symbol>>value:, are there any reasons not to have also
Symbol>>value: anObject value: anotherObject ^ anObject perform: self with: anotherObject
While Symbol>>#value: is at the border of being readable, Symbol>>#value:value: is even worse. It is not immediately obvious what it does. The order of receiver and arguments is hardcoded and thus the construct cannot be applied in most cases without rewriting the code. Fixed arguments cannot be given.
Instead of adding new #value: variants, we should rather try to remove Object>>#value which is a real nightmare ;-)
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ 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
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
_______________________________________________ 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.