[squeak-dev] Changes in imported environments

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Dec 16 22:54:17 UTC 2013


Hi Colin,
There are two things that I'm thinking of:
1) Environment should better be scriptable without user interaction
   It would be even better to have some "declarative" form of Environment.
   I know, all is message send in Smalltalk, so even class definitions are
not declarative...
   but at least classes are able to print an expression that can
reconstruct them.
   The least I'd like for Environment is same kind of trick.
   So it makes me think of other aspects: you're speaking of imports, but
how do we declare the exports?
2) There are several paths from point A to point C, so the solution in case
2 should be robust to declaration order IMHO.
Should the resulting Red depend on which of Green or Blue first added a
Person? This would lead to interesting load order problems.




2013/12/16 Colin Putney <colin at wiresong.com>

> Hi all,
>
> Thinking about how to handle changes in imported environments, I came up
> with the following scenario:
>
> Let's say I have 3 environments, called Red, Blue and Green. My
> application is in Red, and Blue and Green contain packages that my
> application uses. My application has references to a class called Person.
>
> Case 1: shadowed import
>
> Green contains a class called Person, which my app is using. Now I add a
> new class, also called Person, to Blue. Blue's Person is shadowed by
> Green's Person, so it's invisible in Red. New methods compiled in Red will
> continue to reference Green's Person. If I want to use Blue's Person, I'll
> need to create an alias.
>
> Case 2: shadowing import
>
> Blue contains a class called Person, which my app is using. Now I add a
> class, also called Person, to Green. This new binding shadows Blue's
> Person, so the existing binding in Red's references dictionary should be
> replaced with the new binding from Green. Existing methods that refer to
> Person should be rebound.
>
> Now, there's a bunch of other cases to consider, but I suspect that the
> way to handle them becomes obvious once these are sorted out. I have two
> questions:
>
> First, how do we decide which case is which? Currently, imports are done
> in reverse order. Blue is imported first, so bindings in Green shadow those
> in Blue. It occurs to me, though, that it might be easier if we used the
> Traits model here, and only import unambiguous names. Then any
> multiply-defined names would have to be imported.
>
> Second, what sort of UI do we want here? I've been thinking about a kind
> of namespace browser that shows everything visible from an environment and
> gives you commands for importing more bindings, renaming things etc. I'd
> like to avoid having pop-ups all over the place to ask which class you
> want. Environments should represent the record of all those choices so that
> you only have to make them once.
>
> Colin
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131216/d1fd242d/attachment.htm


More information about the Squeak-dev mailing list