>
> On Tue, Aug 24, 2010 at 6:43 PM, Igor Stasenko <
siguctua@gmail.com> wrote:
>> On 25 August 2010 00:14, Gabriel Brunstein <
gaboto@gmail.com> wrote:
>>> Or something like:
>>> self perform: #myMessage asSelector.
>>> It would be just one message in Symbol and not all the selector related protocol
>>>
>>
>> Yeah, and then code things like:
>>
>> 'foo' asSymbol asSelector
>>
>> great idea (pun intended)!
>>
>>> you can also leave the current behavior for that message if your
>>> prefer, in my opinion is not so bad...
>>>
>>>
>>> On Tue, Aug 24, 2010 at 5:27 PM, Nicolas Cellier
>>> <
nicolas.cellier.aka.nice@gmail.com> wrote:
>>>> Following this logic, an object should perform: aSelector rather than aSymbol.
>>>> Thus we should then write (self perform: (#myMessage as: Selector)) in
>>>> order to keep up with conceptual clarity.
>>>> Unless of course we alter the # syntax and let it answer a Selector
>>>> rather than a Symbol ;)
>>>> Then, we could write (#mySymbol as: Symbol), or just remove class Symbol ;)
>>>>
>>>> Seriously ?
>>>>
>>>> Nicolas
>>>>
>>>> 2010/8/24 Gabriel Brunstein <
gaboto@gmail.com>:
>>>>> I like the idea to have a class Selector with all the protocol for
>>>>> selectors there, so any symbol doesn�t have to understand selectors
>>>>> messages.
>>>>> Maybe you don't see short term advanteges of doing that, but I think
>>>>> that it will give conceptual clarity.
>>>>>
>>>>> On Tue, Aug 24, 2010 at 4:27 PM, Igor Stasenko <
siguctua@gmail.com> wrote:
>>>>>> 2010/8/24 Eliot Miranda <
eliot.miranda@gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>> 2010/8/24 Mariano Martinez Peck <
marianopeck@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 24, 2010 at 2:58 PM, Igor Stasenko <
siguctua@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On 23 August 2010 23:26, stephane ducasse <
stephane.ducasse@free.fr>
>>>>>>>>> wrote:
>>>>>>>>> > Hi guys
>>>>>>>>> >
>>>>>>>>> > I'm thinking aloud...
>>>>>>>>> > I was wondering if we could not take advantage of a new class:
>>>>>>>>> > Selector.
>>>>>>>>> > MethodDict would only contain selectors and not symbols.
>>>>>>>>> >
>>>>>>>>> > I remember that I talked about that with hernan.
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> Hmm.. i don't see obvious advantages. Do you?
>>>>>>>>> Most symbols (90% of cases), used as selectors, so it is likely that
>>>>>>>>> such refactoring will be nothing more,
>>>>>>>>> but just renaming the class :)
>>>>>>>
>>>>>>> Personally I find it slightly annoying. �Symbols are only used as selectors
>>>>>>> by convention, and the VM has placed no restriction on what objects can be
>>>>>>> used as selectors so that, e.g. when aggressively shrinking one can replace
>>>>>>> Symbols with SmallIntegers. �Introducing a Selector class would obscure this
>>>>>>> possibility even more. �However I find use of the term "symbol" where
>>>>>>> "selector" is meant even more annoying. �I *hate* methodSymbol in
>>>>>>> MethodReference. �It should be selector.
>>>>>>> 2�
>>>>>>
>>>>>> You're right, any object could be used as a selector, placed into
>>>>>> corresponding method dictionary,
>>>>>> but in practice syntax and compiler implies, that only symbols could
>>>>>> be used as selectors.
>>>>>>
>>>>>> Selector is just a _role_ , and really, VM doesn't puts too much
>>>>>> restrictions on it (thanks to everyone's most liked deity).
>>>>>> In contrast, a Symbol, is a class, and instances of it can play
>>>>>> multiple roles, including being selector.
>>>>>>
>>>>>>> Eliot
>>>>>>>
>>>>>>>>
>>>>>>>> Maybe because there are things implemented in Symbol or similar that are
>>>>>>>> responsabilities of a Selector?
>>>>>>>>
>>>>>>>> I have no idea. But I did a quick search and methods like flushCache,
>>>>>>>> numArgs:,value:, isKeyword, cull:,� etc, seems more from Selector
>>>>>>>>
>>>>>>>> �Cheers
>>>>>>>>
>>>>>>>> mariano
>>>>>>>>
>>>>>>>>>
>>>>>>>>> > Stef
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > _______________________________________________
>>>>>>>>> > Pharo-users mailing list
>>>>>>>>> >
Pharo-users@lists.gforge.inria.fr
>>>>>>>>> >
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>> Igor Stasenko AKA sig.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Pharo-users mailing list
>>>>>>>>>
Pharo-users@lists.gforge.inria.fr
>>>>>>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pharo-project mailing list
>>>>>>>>
Pharo-project@lists.gforge.inria.fr
>>>>>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pharo-project mailing list
>>>>>>>
Pharo-project@lists.gforge.inria.fr
>>>>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Igor Stasenko AKA sig.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>>
Pharo-project@lists.gforge.inria.fr
>>>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>>
Pharo-project@lists.gforge.inria.fr
>>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>>
Pharo-project@lists.gforge.inria.fr
>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>>
Pharo-project@lists.gforge.inria.fr
>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
>
Pharo-project@lists.gforge.inria.fr
>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>