Why doesn't the global environment export anything by default? (Sept 2016, C)
Last updated at 5:37 am UTC on 29 September 2016
Jakob Reschke
Wed, Sep 28, 2016 at 11:17 AM
Reply-To: The general-purpose Squeak developers list
To: The general-purpose Squeak developers list
Let me repeat my question which might have gone unnoticed in my
previous wall of text:
Why doesn't the global environment
Smalltalk globals
export anything by default? Is there a reason at all, or was it simply forgotten at
some point (because "nobody uses Environments" anyway)?
Alternatively: Are there downsides of
Smalltalk globals exportSelf
other than that you have to do it yourself in current Squeak images?
Answer
Nicolas Cellier
Wed, Sep 28, 2016 at 5:51 PM
Reply-To: The general-purpose Squeak developers list
To: The general-purpose Squeak developers list
Reply | Reply to all | Forward | Print | Delete | Show original
2016-09-28 11:17 GMT+02:00 Jakob Reschke :
Let me repeat my question which might have gone unnoticed in my
previous wall of text:
Why doesn't the global environment (Smalltalk globals) export anything
by default? Is there a reason at all, or was it simply forgotten at
some point (because "nobody uses Environments" anyway)?
It's a bug.
Currently, the Environment SUnit tests only work because of strange name scope resolution:
we use the environment of superclass in that resolution with no good reason.
Since ProtoObject/Object are in the class hierarchy, we have undue access to Smalltalk globals.
See below some changes rotting for too long in squeak inbox.
IMO, we should evaluate 'Smalltalk exportSelf' in environment package post actions, then apply the fix below.
http://source.squeak.org/inbox/Kernel-nice.798.diff
Name: Kernel-nice.798
Author: nice
Time: 30 July 2013, 10:34:15.34 pm
UUID: e02ae597-3f6d-40b9-9468-bf01416db6de
Ancestors: Kernel-nice.797
Better fix for http://bugs.squeak.org/view.php?id=1554
A class variable defined in a superclass should take precedence over a global variable.
First look in local class variables.
Then look in local sharedPools (a local sharedPool will shadow a super class variable, that sounds fair).
Then look in superclass pools.
When superclass chain is exhausted, look in the Environment that were provided as parameter.
Note that this is mostly squeak 1.x implementation of #scopeHas:ifTrue: (or st-80), except that anEvironment parameter replaces Smalltalk.
This way we avoid duplicate lookup of previous workaround.
And we never ever look in superclass environment, that's not necessarily ours.
This currently breaks some EnvironmentTest because inheriting superclass environment is a cheap and easy way to import all Smalltalk (unless you are not an Object or ProtoObject of course).
The longest and proper way would be to properly export some symbols from Smalltalk globals, and import them explicitely in the tested environment.
Also don't forget that each environment pretends that Smalltalk globals are pointing to itself (see Environment method initializeWithName:), creating some kind of sand-boxing.
It's nice.
But Smalltalk is now ambiguous ;)
And not so nice at the moment, because some names are misleading now.
Smalltalk globals are not really globals (the variable scope meaning). Or they are globals in their sandbox...
And each Smalltalk is an instance of SmalltalkImage.
Once upon a time SmalltalkImage current was meant for universal access to state of object memory (image as a snapshot) but now what are these "images"?
It looks like unfinished job, with very short term goal (maximizing portability).
I don't know what are the next steps for constructing something solid and consistent. We're not yet there.
Continue reading with
Environment declarations vs. Bindings (Sept 2016, D)
