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 <[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 >
