Symbol>>value:value:
Locked
 
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Tudor Girba-3
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
+1 to the removal of value: from Symbol....
On Wed, May 20, 2009 at 3:18 AM, Lukas Renggli <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]> > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]> >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Tudor Girba-3
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 <[hidden email]> >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]> >>>> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> 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 <[hidden email]> >>>>> 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 >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |