[Pharo-project] Symbol>value:

Mariano Martinez Peck marianopeck at gmail.com
Wed Aug 31 12:26:32 CEST 2011


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 <stephane.ducasse at 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 at 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 at gmail.com>
> wrote:
> >>>> On 30 August 2011 18:02, Douglas Brebner <
> squeaklists at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110831/f1572149/attachment.htm>


More information about the Pharo-project mailing list