[Pharo-project] Symbol>value:
Hi, Symbol responds to #value:, but not to #value:value:. At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows: value: anObject value: anotherObject ^ anObject perform: self with: anotherObject Of course, it should also respond to #value:value:value: and #value:value:value:value: Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
I proposed this some one or two years ago. I got shut down, but I still find it a good idea. And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
From this point of view, they have similar responsibilities and we should be able to treat them the same.
Cheers, Doru On 30 Aug 2011, at 14:12, niko.schwarz@googlemail.com wrote:
Hi,
Symbol responds to #value:, but not to #value:value:.
At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows:
value: anObject value: anotherObject ^ anObject perform: self with: anotherObject
Of course, it should also respond to #value:value:value: and #value:value:value:value:
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- www.tudorgirba.com "Speaking louder won't make the point worthier."
I think it's important to have a consistent answer to the question: "Can you treat symbols as blocks?". Niko On Tue, Aug 30, 2011 at 2:30 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
From this point of view, they have similar responsibilities and we should be able to treat them the same.
Cheers, Doru
On 30 Aug 2011, at 14:12, niko.schwarz@googlemail.com wrote:
Hi,
Symbol responds to #value:, but not to #value:value:.
At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows:
value: anObject value: anotherObject    ^ anObject perform: self with: anotherObject
Of course, it should also respond to #value:value:value: and #value:value:value:value:
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
On 30 Aug 2011, at 14:30, Tudor Girba wrote:
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
From this point of view, they have similar responsibilities and we should be able to treat them the same.
It feels as if this is only the case when the first argument is also the receiver, no ? | adder | adder := [ :x :y | x + y ]. adder value: 1 value: 2. #+ value: 1 value: 2 1 perform: #+ with: 2 Note that the last two expressions are equally short/concise, the second being clearer. Here things become weirder, don't you agree: | creator | creator := [ :x :y | Rectangle origin: 0@0 corner: x@ y ]. creator value: 10 value: 20. #origin:corner: value: Rectangle value: 0@0 value: 10@20 Rectangle perform: #origin:corner: with: 0@0 with: 10@20 Maybe we need more good example of where this would make real sense ? Sven
On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
#+ value: 1 value: 2
1 perform: #+ with: 2
Note that the last two expressions are equally short/concise, the second being clearer.
That is not a comparison worth making. The fair comparison is: [:a :b | a + b] vs #+ Now, I'd say, the second is clearer. With it, Pharo gains support for Tacit programming [1]. Niko [1] http://en.wikipedia.org/wiki/Tacit_programming -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
Maybe we need more good example of where this would make real sense ?
persons select: [:p | p isAdult] persons select: #isAdult persons inject: OrderedCollection new into: [:col :p | col copyWith: p] persons inject: OrderedCollection new into: #copyWith: -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
I have similar definitions from symbol to block for SortedCollection like; #('3' '20' '100') asSortedCollection: #size ascendingSortBlock. "#('3' '20' '100')" #size ascendingSortBlock evaluates to be [:a :b| (a perform: #size) <= (b perform:#size) ] #('3' '20' '100') asSortedCollection: #size descendingSortBlock. "#('100' '20' '3')" Similarly, following can be done #('3' '20' '100') asSortedCollection: #first ascendingSortBlock. #('3' '20' '100') asSortedCollection: #first descendingSortBlock. -- View this message in context: http://forum.world.st/Symbol-value-tp3778525p3778943.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
You just inspired me to a block post on point-free programming :) http://smalltalkthoughts.blogspot.com/2011/08/point-free-programming-in-smal... Niko On 30.08.2011, at 16:57, HwaJong Oh wrote:
I have similar definitions from symbol to block for SortedCollection like;
#('3' '20' '100') asSortedCollection: #size ascendingSortBlock. "#('3' '20' '100')"
#size ascendingSortBlock evaluates to be [:a :b| (a perform: #size) <= (b perform:#size) ]
#('3' '20' '100') asSortedCollection: #size descendingSortBlock. "#('100' '20' '3')"
Similarly, following can be done
#('3' '20' '100') asSortedCollection: #first ascendingSortBlock. #('3' '20' '100') asSortedCollection: #first descendingSortBlock.
-- View this message in context: http://forum.world.st/Symbol-value-tp3778525p3778943.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
On 30 Aug 2011, at 16:16, Damien Cassou wrote:
On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
Maybe we need more good example of where this would make real sense ?
persons select: [:p | p isAdult] persons select: #isAdult
Yes, I am already writing that a lot.
persons inject: OrderedCollection new into: [:col :p | col copyWith: p] persons inject: OrderedCollection new into: #copyWith:
#(1 2 3) inject: 0 into: #+ OK, I am sold ;-) Sven
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector /has/ to be a Symbol. Also, some of the examples in this thread seem to be about terseness for terseness sake.
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;). What i mean that any object may be a selector: MyClass methodDict at: 1 put: someMethod. MyClass new perform: 1 should work. So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :) -- Best regards, Igor Stasenko AKA sig.
It's a question of consistency. Why support value:, but not value:value:? Niko On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
Same question with cull: 2011/8/30 Niko Schwarz <niko.schwarz@googlemail.com>:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
Therefor I suggested to remove Symbol>>#value: the last time this was brought up. If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior). Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments. Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code. Lukas On 30 August 2011 20:09, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- Lukas Renggli www.lukas-renggli.ch
On 30 August 2011 19:34, Lukas Renggli <renggli@gmail.com> wrote:
Therefor I suggested to remove Symbol>>#value: the last time this was brought up.
If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior).
Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments.
Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code.
Like all strong flavours, it's very useful/tasty in small doses. I'm not sure that #inject:into value: #(1 2 3) value: 0 value: #+ is particularly useful. Having said that, I did find it useful playing around with partial continuations to define #compose: on the continuations, symbols and blocks. It made for very readable (IMO at least :) ) code. ZipperControl class >> zipOver: aCollection | f zippers | f := [:a | [:k | Zipper on: a with: (k compose: [:x | x maybe: #yourself default: a])] shift]. ^ [ZipDone on: (aCollection collect: [:each | f value: each])] reset. compared to the original Haskell: make_zipper :: T.Traversable t => t a -> Zipper t a make_zipper t = reset $ T.mapM f t >>= return . ZDone where f a = shift (\k -> return $ Z a (k . maybe a id)) (From http://okmij.org/ftp/continuations/zipper.html#traversable) frank
Lukas
On 30 August 2011 20:09, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- Lukas Renggli www.lukas-renggli.ch
Indeed I would prefer just to have perform: and block value: Stef On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote:
Therefor I suggested to remove Symbol>>#value: the last time this was brought up.
If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior).
Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments.
Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code.
Lukas
On 30 August 2011 20:09, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- Lukas Renggli www.lukas-renggli.ch
My suggestion is the following one: we could add it because there is value: now I would not use it in the core of the system. I hope that one of these days we will be able to bootstrap and identify a kernel and after that we could tag a bit the methods in terms of layers. Stef On Aug 30, 2011, at 9:14 PM, Stéphane Ducasse wrote:
Indeed I would prefer just to have perform: and block value:
Stef
On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote:
Therefor I suggested to remove Symbol>>#value: the last time this was brought up.
If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior).
Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments.
Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code.
Lukas
On 30 August 2011 20:09, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- Lukas Renggli www.lukas-renggli.ch
I arrive late to the discussion, but from my point of view, the correct solution is to create a subclass from Symbol, called Selector ;) and move all those methods there. There are lots of methods in Symbol which in fact only make sense when they are selectors. I know this change will never be done, but that's where those methods like #value: should be placed. I would love to see a clear division between Symbol and Selector. cheers On Tue, Aug 30, 2011 at 9:20 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
My suggestion is the following one: we could add it because there is value: now I would not use it in the core of the system. I hope that one of these days we will be able to bootstrap and identify a kernel and after that we could tag a bit the methods in terms of layers.
Stef
On Aug 30, 2011, at 9:14 PM, Stéphane Ducasse wrote:
Indeed I would prefer just to have perform: and block value:
Stef
On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote:
Therefor I suggested to remove Symbol>>#value: the last time this was brought up.
If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior).
Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments.
Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code.
Lukas
On 30 August 2011 20:09, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner < squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- Lukas Renggli www.lukas-renggli.ch
-- Mariano http://marianopeck.wordpress.com
2011/8/31 Mariano Martinez Peck <marianopeck@gmail.com>:
I arrive late to the discussion, but from my point of view, the correct solution is to create a subclass from Symbol, called Selector ;)Â and move all those methods there. There are lots of methods in Symbol which in fact only make sense when they are selectors. I know this change will never be done, but that's where those methods like #value: should be placed. I would love to see a clear division between Symbol and Selector.
cheers
Don't forget to read http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.user/686 again, and better twice, before deciding anything. Nicolas
On Tue, Aug 30, 2011 at 9:20 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
My suggestion is the following one:     we could add it because there is value: now I would not use it in the core of the system.     I hope that one of these days we will be able to bootstrap and identify a kernel and after that     we could tag a bit the methods in terms of layers.
Stef
On Aug 30, 2011, at 9:14 PM, Stéphane Ducasse wrote:
Indeed I would prefer just to have perform: and block value:
Stef
On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote:
Therefor I suggested to remove Symbol>>#value: the last time this was brought up.
If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior).
Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments.
Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code.
Lukas
On 30 August 2011 20:09, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- Lukas Renggli www.lukas-renggli.ch
-- Mariano http://marianopeck.wordpress.com
That discussion was in another focus. I think that people got confused. When I asked this silly question, I was in fact thinking about the implementation of Selector Namespace in the Smalltalk of david simmons. In fact a symbol (method invocation) was not just foo but namespace1.foo and put like that in the methoddic so you got '==" and "===" for is this symbol truly the same or the same and david implemented selector namespace without changing its vm. Now we are talking about something else. And mariano we could just identify method in Symbols that are - extensions - related to performish operation On Aug 31, 2011, at 3:12 PM, Nicolas Cellier wrote:
2011/8/31 Mariano Martinez Peck <marianopeck@gmail.com>:
I arrive late to the discussion, but from my point of view, the correct solution is to create a subclass from Symbol, called Selector ;) and move all those methods there. There are lots of methods in Symbol which in fact only make sense when they are selectors. I know this change will never be done, but that's where those methods like #value: should be placed. I would love to see a clear division between Symbol and Selector.
cheers
Don't forget to read http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.user/686 again, and better twice, before deciding anything.
Nicolas
On Tue, Aug 30, 2011 at 9:20 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
My suggestion is the following one: we could add it because there is value: now I would not use it in the core of the system. I hope that one of these days we will be able to bootstrap and identify a kernel and after that we could tag a bit the methods in terms of layers.
Stef
On Aug 30, 2011, at 9:14 PM, Stéphane Ducasse wrote:
Indeed I would prefer just to have perform: and block value:
Stef
On Aug 30, 2011, at 8:34 PM, Lukas Renggli wrote:
Therefor I suggested to remove Symbol>>#value: the last time this was brought up.
If you keep it, besides all the variations of #value:... you also need to consider #cull:, #cull:cull:, #cull:cull:cull:, #valueWithArguments:, valueWithEnoughArguments:, #valuWithPossibleArgs:, #valueWithPossibleArguments:; as well as somebody needs to fix #numArgs (which is highly inconsistent with a block that has the same behavior).
Also for many asymmetric selectors the trick does not work (e.g. #join:, #matches:, #includesSubString:, ...) because you need to turn around the arguments.
Aside from the above, evaluable selectors hamper readability: Back in 2005 Magritte added #value: and #value:value: as method extensions. You can go and read all the mails of people having troubles reading the code. The benefit of writing a few characters less is really not worth the trouble spent digesting the code.
Lukas
On 30 August 2011 20:09, Niko Schwarz <niko.schwarz@googlemail.com> wrote:
It's a question of consistency. Why support value:, but not value:value:?
Niko
On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;).
What i mean that any object may be a selector:
MyClass methodDict at: 1 put: someMethod.
MyClass new perform: 1
should work.
So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
Yeah. I have same impression. But its cool :)
-- Best regards, Igor Stasenko AKA sig.
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
-- Lukas Renggli www.lukas-renggli.ch
-- Mariano http://marianopeck.wordpress.com
On Aug 30, 2011, at 6:02 PM, Douglas Brebner wrote:
On 30/08/2011 13:30, Tudor Girba wrote:
I proposed this some one or two years ago. I got shut down, but I still find it a good idea.
And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input.
I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol.
It was just a stupid idea of mine :)
Also, some of the examples in this thread seem to be about terseness for terseness sake.
makes sense. http://code.google.com/p/pharo/issues/detail?id=4726 Stef On Aug 30, 2011, at 2:12 PM, niko.schwarz@googlemail.com wrote:
Hi,
Symbol responds to #value:, but not to #value:value:.
At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows:
value: anObject value: anotherObject ^ anObject perform: self with: anotherObject
Of course, it should also respond to #value:value:value: and #value:value:value:value:
Niko
-- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
participants (13)
-
Damien Cassou -
Douglas Brebner -
Frank Shearar -
HwaJong Oh -
Igor Stasenko -
Lukas Renggli -
Mariano Martinez Peck -
Nicolas Cellier -
Niko Schwarz -
niko.schwarz＠googlemail.com
-
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba