Hello
I wanted to see what you think about having a class Selector vs using Symbols. Apparently in Dave Simmons Smalltalk he could overrides Symbol to get selector namespace by providing === and = which would take namespace into account or not.
Stef
stephane ducasse wrote:
I wanted to see what you think about having a class Selector vs using Symbols. Apparently in Dave Simmons Smalltalk he could overrides Symbol to get selector namespace by providing === and = which would take namespace into account or not.
If you recall the m17n String reorganization, I had originally considered to change the string hierarchy to look like this: String ByteString[indexed bytes] WideString[indexed words] Symbol('string') I.e., Symbol holds an instance of String instead of having the current Symbol/ByteSymbol/WideSymbol hierarchy. The main reason not to do that was that the VM does assume that class names and selectors are byte indexable objects.
If you are willing to either ignore or fix the resulting issues, I see no problem with having a Selector class (even one per namespace, i.e., selectors could be anonymous subclasses of Selector that are intrinsically bound to the namespace where they are defined in). In which case you could use a system-wide default "Selector" namespace which is used for current code and use the per-namespace selectors for any new code you write which is aware of the differences.
In any case, it should be *extremely* simple to experiment with this approach in Squeak.
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org