[squeak-dev] Environments

Frank Shearar frank.shearar at gmail.com
Thu Jul 5 19:41:46 UTC 2012


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


> 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