[squeak-dev] The Inbox: Environments-fbs.3.mcz

Colin Putney colin at wiresong.com
Fri Jul 27 16:59:49 UTC 2012

On Fri, Jul 27, 2012 at 7:48 AM, Frank Shearar <frank.shearar at gmail.com> wrote:

> I'm struggling to write a test for this. I thought this would work:
> testLookupOfMisspelledClassNamePromptsUser
>         | griffle |
>         self createClass: #Griffle.
>         griffle := env at: #Griffle.
>         self should: [griffle compile: 'nowTime ^ TimStamp new'] raise:
> UndeclaredVariable.
> but it doesn't. First it fails because there's no UndeclaredVariable,
> but the second time it runs, even though env at: #TimStamp is
> KeyNotFound, inspecting the env and evaluating "TimStamp" yields nil.
> That's fine if you're in a WorkSpace, which will automatically create
> bindings for you, but not so much here.
> Or am I misreading my test failure? Could an inspector autocreate the
> binding? Even though the env's undeclared is empty, the root
> environment's contains #TimStamp->nil.

The problem is that we don't support multiple environments yet. The
trunk doesn't have all the functionality of the prototype environments
image. We've migrated from SystemDictionary to an Environment in
"Smalltalk globals" but the changes to Compiler and other support code
haven't been made yet. So even though you're compiling a method on a
class in your test environment, the global environment is what is
actually being used.

Your intuition is right. Management of the Undeclared namespace should
be the responsibility of the environment. That refactoring should be
part of the Compiler changes that I'm about to start on.

As for this test, we could make an expected failure for now, or we
could do a version that explicitly uses the global environment, and
change it later when multiple environments are supported.


More information about the Squeak-dev mailing list