>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
Locked
