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

	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…