On Sun, Dec 22, 2013 at 11:38 AM, Levente Uzonyi <leves at elte.hu> wrote:

> 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.
> You don't want a class defined in your environment to be shadowed by
> another class from an imported environment, do you?


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.

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.

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.

Let's not close off possibilities just to save a message send when building
an environment.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131222/4d58d8ce/attachment.htm