The Inbox: Environments-fbs.3.mcz

Frank Shearar uploaded a new version of Environments to project The Inbox:
http://source.squeak.org/inbox/Environments-fbs.3.mcz

==================== Summary ====================

Name: Environments-fbs.3
Author: fbs
Time: 27 July 2012, 3:45:30.98 pm
UUID: f4f0bbda-663d-407b-8dbd-976eb031d247
Ancestors: Environments-cwp.2

Using a Workspace, if you misspell a classname you get a walkback because Environment doesn't understand #keysDo:. Implementing it results in the desired spelling correction prompt.

=============== Diff against Environments-cwp.2 ===============

Item was added:
+ ----- Method: Environment>>keysDo: (in category 'enumerating') -----
+ keysDo: aBlock
+ "Evaluate aBlock for each of the receiver's keys."
+
+ contents keysDo: aBlock!

On 27 July 2012 15:45,  <[hidden email]> 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.

frank

On Fri, Jul 27, 2012 at 7:48 AM, Frank Shearar <[hidden email]> wrote:

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.

Colin