On Fri, Jan 11, 2013 at 1:28 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> I do wonder why Class>>bindingOf:environment: looks into the environment
> first, however. This means that a global variable would shadow an inherited
> class variable or pool variable, which is against my intuition of how
> scoping works. Does anyone know why this would be intended?


When adding the environment: argument, I preserved the existing logic from
Class>>bindingOf:, so as not to break anything while bootstrapping, but I
agree it's wrong.

I suspect that this is a holdover from the original Environments
implementation, which lacked import/export between environments. Letting an
environment shadow variables is the only way to override the superclass's
environment. And without a way to do that, there can only be one
environment!

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130113/67e55d8a/attachment.htm