That discussion was in another focus. I think that people got confused. When I asked this silly question, I was in fact thinking about the implementation of Selector Namespace in the Smalltalk of david simmons. In fact a symbol (method invocation) was not just foo but namespace1.foo and put like that in the methoddic so you got '==" and "===" for is this symbol truly the same or the same and david implemented selector namespace without changing its vm. Now we are talking about something else. And mariano we could just identify method in Symbols that are - extensions - related to performish operation On Aug 31, 2011, at 3:12 PM, Nicolas Cellier wrote:
2011/8/31 Mariano Martinez Peck <marianopeck@gmail.com>:
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 <stephane.ducasse@inria.fr> 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 <niko.schwarz@googlemail.com> 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 <siguctua@gmail.com> wrote:
On 30 August 2011 18:02, Douglas Brebner <squeaklists@fang.demon.co.uk> 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