<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 22, 2013 at 11:38 AM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">It shouldn't be imported at all. I think the only reason why an environment is importing itself is to make the lookup in #bindingOf: work. But since we have to change the binding lookup - because it's the source of all kind of bugs - we can easily get rid of importing self.</span><br>
</div>
You don't want a class defined in your environment to be shadowed by another class from an imported environment, do you?</blockquote><div><br></div><div>You might. The point of environments is to give you control over what names are bound to what objects. That does allow for some strange environments to be built, and if we prevent stupid things we also prevent clever things. </div>
<div><br></div><div>For example, imagine a sandboxed environment where, for security reasons, you can't override the classes that are built into the sandbox. You can define a class named Array, but you can't trick somebody into using it, because any references to "Array" will always bind to the system-provided class. </div>
<div><br></div><div>Or, what if we used an environment to bootstrap a new image? We might want to create base classes like Behavior or Class while still being able to use the host image classes until the new image has been fully built. </div>
<div><br></div><div>Let's not close off possibilities just to save a message send when building an environment.</div><div><br></div><div>Colin</div></div></div></div>