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.
Ok. I was thinking the inverse. But again I was gazing at my screen and this idea cross it so I did not think more than that.
However I find use of the term "symbol" where "selector" is meant even more annoying. I *hate* methodSymbol in MethodReference. It should be selector.
Me too :) Actually I wanted to play with the following idea if I find a fun student. We say ok we have packages/modules and we have a sealing mechanism and inside a seal package, ugly things can happen like aggressive inlining and one idea was also removing symbol method selectors. I'm curious what we could get.
2¢ 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