Back in the time of ModularSmalltalk and S#, we had fierce discussions on a symbol resolution to implement selector namespaces. We had something like that:
Symbol + Namespace = selector As a result, several namespaces could define a method with the same selector on a same class, thus avoiding clashes between class extensions. Cheers, Alexandre > On May 13, 2015, at 9:46 AM, Sean P. DeNigris <s...@clipperadams.com> wrote: > > Igor Stasenko wrote >> Symbol + ??? => Selector >> >> give me a strong reason. >> >> i like the idea of shrinking a Symbol's protocol and putting it into >> lean and clean place - Symbol. > > While fixing Issue 15523: "Code Cruft Rule Only Matches One-Liners", I > reeeeeally wanted: > Selector > UnarySelector > BinarySelector > KeywordSelector > so that I could double dispatch. It made me remember this old interesting > thread. So, in addition to the conceptual clarity reification would provide, > this provided a clear (to me) case of technical benefit. We could eliminate > the ~20 or so senders of isUnary, ~20 of isBinary, and ~20 isKeyword in the > Kernel for a start... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/funny-idea-Symbol-vs-Selector-tp2335774p4826193.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
