Having raised all of these questions, I'm not sure of the ultimate 
virtue of the feature.  Is it good programming style to use, hence to 
support, a module-specific use of a "little cap" squeak entity, 
particularly a non-object?

Perhaps the better notion to use a subclass instead?

Which is the better programming style?   I am fearful we can end up with 
highly unmaintainable coding scenarios -- precisely the problem that 
Modularity was supposed to avoid.

Now, I was never inculcated with Envy, so please don't flame me.  On 
this question, count me a newbie.  But, I'd sure like some introduction 
to how this all would work from a user's perspective, and why it would 
be a "good thing." (R)


On Thursday, August 16, 2001, at 04:34 PM, Stephen Pair wrote:

> (one addition point)
>
>>> The difference is that "'add:' asSymbol" would always yield
>> the same
>>> object no matter which module you are in.
>>
>> This could be done in either approach. Since you do have to
>> modify the compiler to generate the prefix bytes you could
>> equally well define that only a compiler lookup will go
>> through the local selector name space.
>
> True, but if you have a selector in hand, you will eventually come
> across situations where you need to determine in which module that
> symbol was defined.  Searching through all modules in the system and
> inspecting the local symbol tables would not be very efficient.
>
> On the other hand, adding a module instance variable to the selector
> (logically speaking) that references the module in which it was defined
> has the benefit of being able to quickly lookup the module, while at the
> same time not require any additional symbol tables.  The compiler could
> even quicky determine if the module (or any of its imports have) defined
> a selector, and if not, optimize out the module prefix.  Changing a
> module's prerequisites, or adding a new method, would require that any
> methods sending that message (in the module or its dependents) be
> re-compiled (but this is only needed for optimization).
>
> Collecting all symbols defined by a module would only require plucking
> them out of the symbol table, and if desired, this too could be
> optimized by keeping a local symbol table for each module (and keeping
> it in sync with the main symbol table).
>
> - Stephen
>
>
>