>I can confirm that this works. Curious, it seems like
>#evaluate:environment: implicitly looks up names in the default
>Environment as a fallback. The created WbSrvr Environment does not
>have a binding for Object:
> env valueOf: #Object => nil.
>But:
> Compiler evaluate: 'Object' environment: env => Object
> Compiler evaluate: 'Object environment' environment: env => Smalltalk
> Compiler evaluate: 'WebServer environment' environment: env => WbSrvr
>That is probably the kind of stuff that must be documented.
I don't know that it's a fallback. I think an Environment only has
access to the policy you give it. More specifically to what the Compiler
is allowed to see. And an Environment cannot exist without being
compiled. I think that's what the binding policy is. In Nicolas's
example he had:
spanish := Environment withName: 'Spanish'.
spanish importSelf.
spanish from: english import: #Transcript.
I think the #importSelf creates an AllNamePolicy and the #from:import:
an ExplicitNamePolicy. If you take the last line out (#from:import:) his
example works just the same. I don't think you need to specify you want
Transcript. The compiler can see it already from the #importSelf in the
AllNamePolicy.
So, your three examples basically make sense to me. I think your line of
reasoning is solid, though, because understanding the nature of the
barrier between Environments is both essential and at the moment pretty
hazy. I just want to say 'fallback' may be the wrong word. It can only
fall back on any policy it's given and AllNamePolicy doesn't sound too
discriminating. I think that may be what's happening.
I guess the compiler doesn't check to see if what you want to do is
possible. It just plays along or shrugs. If there were tests for an
Environment or the the compiler acted like C and said "I see what you're
trying to do there, but that's not going to happen." Then the nature of
the barrier between environments would become tactile. The errors would
teach the nature of the barrier.
>As for the "for added fun" part: In my image there is no accessor for
>the Process environment (and it is not a fully-fledged Environment
>instance, but a Dictionary, when you use Process>>environmentAt: and
>friends), so I had to add that accessor myself.
Right, yea. Exactly. I just used the "add accessors" menu item to add
it. I noticed somebody wrote into Process an #env ivar already, and it
looked unused, so I supposed I could employ it when each process is
initialized. Then I could inspect a process in the ProcessBrowser.
Your change to Compiler>>evaluteCue:ifFail: looks great. I'm looking
forward to trying that out. I had a feeling that if I threw that
question out there that a better programmer could solve that.
Chris