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, [hidden email] 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 <[hidden email]> 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, [hidden email] 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 |
In reply to this post by Tudor Girba-2
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 <[hidden email]> 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 |
In reply to this post by Sven Van Caekenberghe
On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe <[hidden email]> 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 |
> persons inject: OrderedCollection new into: [:col :p | col copyWith: p]
> persons inject: OrderedCollection new into: #copyWith: Or this one: #(3 2 1) asSortedCollection: [:a :b | a <= b] #(3 2 1) asSortedCollection: #<= |
In reply to this post by Damien Cassou
On 30 Aug 2011, at 16:16, Damien Cassou wrote: > On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe <[hidden email]> 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 |
In reply to this post by niko.schwarz
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. |
In reply to this post by Tudor Girba-2
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. |
In reply to this post by HwaJong Oh
You just inspired me to a block post on point-free programming :)
http://smalltalkthoughts.blogspot.com/2011/08/point-free-programming-in-smalltalk.html 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 |
In reply to this post by Douglas Brebner
On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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 <[hidden email]> wrote: > On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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 <[hidden email]>: > 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 <[hidden email]> wrote: >> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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 > > |
In reply to this post by niko.schwarz
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 <[hidden email]> 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 <[hidden email]> wrote: >> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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 |
In reply to this post by niko.schwarz
makes sense.
http://code.google.com/p/pharo/issues/detail?id=4726 Stef On Aug 30, 2011, at 2:12 PM, [hidden email] 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 > > |
In reply to this post by Lukas Renggli
On 30 August 2011 19:34, Lukas Renggli <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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 > > |
In reply to this post by Douglas Brebner
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. > |
In reply to this post by Lukas Renggli
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 <[hidden email]> 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 <[hidden email]> wrote: >>> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>> On 30 August 2011 18:02, Douglas Brebner <[hidden email]> 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 >> > > |
Free forum by Nabble | Edit this page |