Posted by
Tobias Pape on
Sep 29, 2016; 7:14pm
URL: https://forum.world.st/Environment-declarations-vs-bindings-tp4917382p4917467.html
On 29.09.2016, at 20:57, Frank Shearar <
[hidden email]> wrote:
>
>>
>> Environment current
>>
>> is parallel to
>>
>> Project current
>>
>> I think this is OK.
>>
>> @Frank, could you elaborate please what you mean with '_delimited
>> dynamic variable_' ?
>
> Well, I like to be precise with my terminology. The tl;dr is that a delimited dynamic variable is just like what other people call a dynamic variable, except it plays nicely with stack slicing. The throw-a-Notification-get-an-answer idiom is exactly equivalent to delimited dynamic variables
>
>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-February/176777.html has a bit of a conversation around the topic, and has pointers to in-depth articles on delimited dynamic binding, and I've done my small part in trying to dig into the topic here:
http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables/.
>
> Anyway, the fundamental point I was trying to make is that using a Notification (CurrentEnvironment) is exactly avoiding global state, but it seems I missed the point that you and Nicolas were making, around various things having a #environment property.
A note: The first time I had seen a dynamic variable was in seaside where
it is/was used for accessing the 'request context' (Being a web framework, this thingy described the HTTP request received by the framework).
To access that, you call
self requestContext zork
in you seaside class, which boils down to
requestContext
^ CurrentRequestContext value
And CurrentRequestContext being a Dynamic Variable implemented as Notification.
However, since then, we have merged in the DynamicVariable as ProcessSpecificVariable contributed by Martin von Löwis.
This provides a more efficient way to 'resolve' the DV to a value, because the Notification-based DV needs to peel the stack and re-built it (particularly hurting Cog) whereas the ProcessSpecificVariable-based DV 'just' needs some Dict-lookups in the current Process.
========
I quite like accessing the current Environment via a dynamic variable, as it exactly provides the control-flow scope that is necessary for this kind of thing.
We should however adopt a proper DV here, increasing efficiency and readability.
No more 'CurrentEnvironment signal ifNil: […]'
but rather
Object>>environment
^ CurrentEnvironment value
and
DynamicVariable subclass: #CurrentEnvironment
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: '...'
and
CurrentEnvironment class>>default
^ Smalltalk globals
and then, for example
EnvironmentLoader>>evaluate: chunk
^ CurrentEnvironment use: environment during:
[Compiler evaluate: chunk environment: environment]
(not tested, tho)
Best regards
-Tobias
PS: I sometimes call DVs semi-globals. not really global, not really non-global…