<div dir="ltr"><div><div><div>Hi Colin,<br>There are two things that I&#39;m thinking of:<br></div>1) Environment should better be scriptable without user interaction<br></div><div>   It would be even better to have some &quot;declarative&quot; form of Environment.<br>
</div><div>   I know, all is message send in Smalltalk, so even class definitions are not declarative...<br>   but at least classes are able to print an expression that can reconstruct them.<br></div><div>   The least I&#39;d like for Environment is same kind of trick.<br>
   So it makes me think of other aspects: you&#39;re speaking of imports, but how do we declare the exports?<br></div>2) There are several paths from point A to point C, so the solution in case 2 should be robust to declaration order IMHO.<br>
Should the resulting Red depend on which of Green or Blue first added a Person? This would lead to interesting load order problems.<br><br></div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/16 Colin Putney <span dir="ltr">&lt;<a href="mailto:colin@wiresong.com" target="_blank">colin@wiresong.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>Thinking about how to handle changes in imported environments, I came up with the following scenario:</div>
<div><br></div><div><div>Let&#39;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. </div>

<div><br></div></div><div>Case 1: shadowed import</div><div><br></div><div>Green contains a class called Person, which my app is using. Now I add a new class, also called Person, to Blue. Blue&#39;s Person is shadowed by Green&#39;s Person, so it&#39;s invisible in Red. New methods compiled in Red will continue to reference Green&#39;s Person. If I want to use Blue&#39;s Person, I&#39;ll need to create an alias.</div>

<div><br></div><div><div>Case 2: shadowing import<br></div></div><div><br></div><div>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&#39;s Person, so the existing binding in Red&#39;s references dictionary should be replaced with the new binding from Green. Existing methods that refer to Person should be rebound.</div>

<div><br></div><div>Now, there&#39;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:</div><div><br></div><div>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.</div>

<div><br></div><div>Second, what sort of UI do we want here? I&#39;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&#39;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.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Colin</div><div><br></div><div><br></div></font></span></div>
<br><br>
<br></blockquote></div><br></div>