2011/8/31 Mariano Martinez Peck <[email protected]>: > 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 >
Don't forget to read http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.user/686 again, and better twice, before deciding anything. Nicolas > 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 > >
