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.
