[Pharo-project] Symbol>>value:value:
Hi, 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 ? Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
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
+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
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
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."
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
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Maybe an alternative would be to use Helvetia to write blocks in shorthand. Currently, writing the whole [:each | each abs] is a bit of a pain, so the much shorter #abs is nice. But what if there was [⦠abs], the ellipsis meaning "it" or "the argument, duh" ? Several instances of ⦠could be used in order: [⦠foo: ⦠bar: â¦] being equivalent to #foo:bar: value: x value: y value: z or [:x :y :z | x foo: y bar: z] Actually that problem exists in functional languages with partial application, you can only apply the arguments in order, else you have to name them (except with infix operators in Haskell, where (+2) is (\x x+2) and (2+) is (\x 2+x). I was thinking that in OCaml, one could write foo _ 42 to partially apply function foo to its second argument. On Fri, May 22, 2009 at 13:47, Alexandre Bergel <alexandre@bergel.eu> wrote:
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
self collect: #abs
Yes, that looks cool. However it is difficult to understand what it does for #(-2 3 4) - Does it collect the literal #abs for all the values of the collection? --> #(abs abs abs) - Does it collect the values of performing #abs on the collection? --> #(2 3 4) With #value:value: you even have more freedom, and it is even less clear how the result is obtained. The implementation given by the original poster might work in one (common) case, but this is definitely not the only way to use a symbol for evaluation. In Seaside 2.9 there are the classes WADelayedSend, WABoundDelayedSend and WAUnboundDelayedSend that are polymorphic to block closures and that reify different forms of message sends as first class objects. GNU Smalltalk has a similar construct built into their core library. I think that using symbols is a rather poor approach to model message sends. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
do you have a scenario for it? And I agree with lukas about value on Object Stef On May 20, 2009, at 12:52 AM, Tudor Girba wrote:
Hi,
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
?
Cheers, Doru
-- www.tudorgirba.com
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Alexandre Bergel -
Damien Pollet -
Gabriel Cotelli -
Lukas Renggli -
Stéphane Ducasse -
Tudor Girba