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