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