[squeak-dev] Environments

Frank Shearar frank.shearar at gmail.com
Thu Jul 5 19:43:05 UTC 2012

Sigh. Send accident there.

On 5 July 2012 20:41, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 5 July 2012 18:15, Colin Putney <colin at wiresong.com> wrote:
>> On Thu, Jul 5, 2012 at 8:11 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> Right. So what you're saying is that if you want proper modules, you
>>> need VM support.
>> Not necessarily. For the next experiment, I've been thinking about
>> implementing selector spaces. Here's how it might work:
>> • Each environment has its own Symbol table
>> • The scanner delegates interning of symbols to the environment
>> • When interning a symbol the environment searches its imports
>> • If no imported environment has the symbol, it creates one in its own
>> symbol table
> Does that mean that given libraries Foo and Bar that both define
> Object >> #thing, you provide some conflict resolution (say, {#thing1
> -> (Foo at: #Object) >> #thing.}), and then in your Environment you
> have some method
> doIt

  ^ self thing1

that the scanner turns that into a #thing sent to Foo's Object?


>> This would mean that an environment could add extension methods to
>> classes in other environments, without colliding with other
>> extensions. It would also make it possible to create "private
>> overrides" where only code in that environment would use the override.
>> It might be useful for sandboxing, but might not be sufficient.
>> I want to stress, though, that this is *not* part of the current
>> proposal—it's just some ruminating about what the next experiment
>> might be, someday.
> And while I'm drooling about the idea of a modular Squeak environment,
> what can I/we do to help this first stage?
>> Colin

More information about the Squeak-dev mailing list