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 <[email protected]> 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 <[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 > > -- Lukas Renggli www.lukas-renggli.ch
