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