[squeak-dev] About Selector vs Symbol

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] About Selector vs Symbol

stephane ducasse
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



Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: About Selector vs Symbol

Andreas.Raab
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