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 <[email protected]> wrote: > On 30 August 2011 18:02, Douglas Brebner <[email protected]> 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
