[squeak-dev] Environment declarations vs bindings
Das.Linux at gmx.de
Thu Sep 29 19:19:27 UTC 2016
On 29.09.2016, at 20:57, Frank Shearar <frank.shearar at gmail.com> 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
^ 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: […]'
^ CurrentEnvironment value
DynamicVariable subclass: #CurrentEnvironment
^ Smalltalk globals
and then, for example
^ CurrentEnvironment use: environment during:
[Compiler evaluate: chunk environment: environment]
(not tested, tho)
PS: I sometimes call DVs semi-globals. not really global, not really non-global…
More information about the Squeak-dev