I arrive late to the discussion, but from my point of view, the correct solution is to create a subclass from Symbol, called Selector ;) and move all those methods there. There are lots of methods in Symbol which in fact only make sense when they are selectors. I know this change will never be done, but that's where those methods like #value: should be placed. I would love to see a clear division between Symbol and Selector.
cheers On Tue, Aug 30, 2011 at 9:20 PM, Stéphane Ducasse <[email protected] > wrote: > 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 <[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 > >> > > > > > > > -- Mariano http://marianopeck.wordpress.com
