<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 September 2016 at 10:42, H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 9/29/16, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
> On 29 September 2016 at 10:10, Nicolas Cellier <<br>
> <a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@<wbr>gmail.com</a>> wrote:<br>
><br>
>><br>
>><br>
>> 2016-09-29 18:39 GMT+02:00 Jakob Reschke <<a href="mailto:jakob.reschke@student.hpi.de">jakob.reschke@student.hpi.de</a>><wbr>:<br>
>><br>
>>> Many questions should be answered with tooling here, but in the<br>
>>> particular case I mentioned, IMHO it is not about tooling. Until now,<br>
>>> code that does `Smalltalk at: something` wants to look up something<br>
>>> dynamically or it can't be sure that this class is actually loaded. As<br>
>>> there was only one place to do such lookups, no differentiation about<br>
>>> visibility or the source of a binding was necessary.<br>
>>><br>
>>> Instances of `Smalltalk at: something` should either be replaced by an<br>
>>> environment aware equivalent that makes clear if a name should be<br>
>>> looked up *only* in the receiving environment (in its declarations),<br>
>>> or if a name should be resolved, looking also in imported environments<br>
>>> (in the bindings).<br>
>><br>
>><br>
>> Agree<br>
>><br>
>><br>
>>> As it is inconvenient to find all these pieces of<br>
>>> code and change them all, `Smalltalk (globals)` could be the "active"<br>
>>> environment (currently via dynamic scoping with `on:<br>
>>> CurrentEnvironment do: ...`), not the original global environment.<br>
>><br>
>><br>
>> I don't like the idea of CurrentEnvironment at all. IMO global state<br>
>> stinks.<br>
>> It would mean that a lotta behavior would change by simply switching one<br>
>> shared variable...<br>
>> I see it more like a not so clever workaround to make tools still work in<br>
>> presence of environments with minimal changes.<br>
>><br>
><br>
> Global state does indeed stink, which is why Environments is so nice,<br>
> because "global" isn't global anymore.<br>
><br>
> But that's the whole point of CurrentEnvironment - it's a _delimited<br>
> dynamic variable_, turning formerly actually global state into something<br>
> context sensitive.<br>
<br>
</div></div> Environment current<br>
<br>
is parallel to<br>
<br>
Project current<br>
<br>
I think this is OK.<br>
<br>
@Frank, could you elaborate please what you mean with '_delimited<br>
dynamic variable_' ?<br></blockquote><div><br></div><div>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</div><div><br></div><div><a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-February/176777.html">http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-February/176777.html</a> 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: <a href="http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables/">http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables/</a>.</div><div><br></div><div>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.</div><div><br></div><div>frank</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
--Hannes<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> frank<br>
><br>
><br>
><br>
>> But<br>
>>> then Environment>>at: must behave sensibly. I would expect that I can<br>
>>> always do `Smalltalk at: #Object` to retrieve `Object` in any<br>
>>> environment (under the assumption that every environment would import<br>
>>> the "Kernel" or original environment). This is currently not the case,<br>
>>> because Environment>>at: looks only into an environment's (own)<br>
>>> declarations, not the imported bindings.<br>
>>><br>
>>><br>
>> I don't know. Maybe (Smalltalk at: #Foo) is questionable by itself.<br>
>> VW did introduce #{Foo} ifPresent: [:foo | ] or something like that for<br>
>> deferred bindings.<br>
>> I remind you that Smalltalk itself is a global variable created with a<br>
>> different instance for each environment.<br>
>><br>
>> Object is in the superclass chain, so we can still access with superclass<br>
>> superclass ... environment.<br>
>><br>
>><br>
>><br>
>>> 2016-09-29 17:30 GMT+02:00 Nicolas Cellier<br>
>>> <nicolas.cellier.aka.nice@gmai<br>
>>> <a href="http://l.com" rel="noreferrer" target="_blank">l.com</a>>:<br>
>>> ><br>
>>> ><br>
>>> > 2016-09-29 15:15 GMT+02:00 Jakob Reschke<br>
>>> > <<a href="mailto:jakob.reschke@student.hpi.de">jakob.reschke@student.hpi.de</a>><br>
>>> :<br>
>>> >><br>
>>> >> Hi,<br>
>>> >><br>
>>> >> Environment>>associationAt: is part of the Smalltalk globals<br>
>>> >> Dictionary compatibility interface, right? As a quick and dirty fix,<br>
>>> >> I<br>
>>> >> changed instances of Smalltalk at: xyz in Monticello code to<br>
>>> >> CurrentEnvironment signal at: xyz, but #at: also only reads in the<br>
>>> >> declarations, so myEnvironment at: #MCWriter or myEnvironment at:<br>
>>> >> #Object returns nil by default. It would make more sense to perform a<br>
>>> >> full lookup via #valueOf:ifAbsent: in #at: and its cousins, wouldn't<br>
>>> >> it?<br>
>>> >><br>
>>> >> Best,<br>
>>> >> Jakob<br>
>>> >><br>
>>> ><br>
>>> > I imagine that the question is about tools.<br>
>>> > For now Smalltalk importSelf, so bindings and declarations do agree.<br>
>>> > If an Environment does not importSelf, then some variables will be<br>
>>> > invisibles (unbounds). Do we still want to see them in some tool, or<br>
>>> not?<br>
>>> > What's going on if we play with Alias? Do we want to see the Alias in<br>
>>> some<br>
>>> > browser? If not, then we'd better stick with declarations.<br>
>>> > There is no easy solution. A single facade for two dictionaries cannot<br>
>>> fit<br>
>>> > all, so we need several different messages.<br>
>>> > But it's much about what we want to do with those environments.<br>
>>> ><br>
>>> ><br>
>>> >><br>
>>> >> 2016-09-29 7:33 GMT+02:00 H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>>:<br>
>>> >> > On 9/28/16, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@<wbr>gmail.com</a>><br>
>>> wrote:<br>
>>> >> >> Since we are at reviewing Environment, here is a small detail that<br>
>>> >> >> bothers<br>
>>> >> >> me. I already asked some months ago, but silence was the only<br>
>>> response,<br>
>>> >> >> so<br>
>>> >> >> ping.<br>
>>> >> >><br>
>>> >> >> Implementation of Environment is sometimes not obvious:<br>
>>> >> >> - Environment>>associationAt: uses declarations inst.var..<br>
>>> >> >> - Environment>><wbr>associationOrUndeclaredAt: uses bindings inst.var.<br>
>>> >> >> How can it be so different, the selector does not speak, does it?<br>
>>> >> >><br>
>>> >> >> OK, there is a flag: #review in one of them, but that does not<br>
>>> >> >> make<br>
>>> >> >> code<br>
>>> >> >> clearer, it's just a smell of over-complexity or ill-naming.<br>
>>> >> >><br>
>>> >> >> Whatever the reason (self explaining code?) Colin does not comment<br>
>>> >> >> class/methods, that's a fact.<br>
>>> >> ><br>
>>> >> > Alternatively a description of the general ideas and the mechanism<br>
>>> would<br>
>>> >> > help.<br>
>>> >> ><br>
>>> >> > After all Environments is just a clever combination of a few<br>
>>> >> > dictionaries to look up class names? Isn't it? ;-)<br>
>>> >> ><br>
>>> >> > However the fact that people did not move on much finalising the<br>
>>> >> > implementation of environments since 2012 shows that it is hard to<br>
>>> >> > reverse-engineer the intentions from the (incomplete) code.<br>
>>> >> ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> >> Chris made the effort of commenting Environment but then came this<br>
>>> >> >> declarations/bindings split, and the comment did rapidly rot.<br>
>>> >> >> We have here an un-healthy statu quo crying for change.<br>
>>> >> >><br>
>>> >> >> So if we want to at least comment the class with the<br>
>>> >> >> meaning/role/responsibility of inst vars, here is my<br>
>>> >> >> understanding:<br>
>>> >> >><br>
>>> >> >> environment bind: #Foo to: 0. just add to the declarations.<br>
>>> >> >> (You see how names are not obvious: bind does not bind the new<br>
>>> binding<br>
>>> >> >> to<br>
>>> >> >> bindings).<br>
>>> >> ><br>
>>> >> > Environments<br>
>>> >> ><br>
>>> >> > bind: aSymbol to: anObject<br>
>>> >> > | binding newBinding |<br>
>>> >> > newBinding := aSymbol => anObject.<br>
>>> >> ><br>
>>> >> > binding := declarations associationAt: aSymbol ifAbsent:<br>
>>> [nil].<br>
>>> >> > binding ifNotNil:<br>
>>> >> > [binding class == newBinding class<br>
>>> >> > ifTrue: [binding value: anObject]<br>
>>> >> > ifFalse: [binding becomeForward:<br>
>>> >> > newBinding].<br>
>>> >> > ^anObject].<br>
>>> >> ><br>
>>> >> > binding := undeclared associationAt: aSymbol ifAbsent:<br>
>>> >> > [nil].<br>
>>> >> > binding<br>
>>> >> > ifNil: [binding := newBinding]<br>
>>> >> > ifNotNil:<br>
>>> >> > [undeclared removeKey: aSymbol.<br>
>>> >> > binding class == newBinding class<br>
>>> >> > ifTrue: [binding value: anObject]<br>
>>> >> > ifFalse: [binding becomeForward:<br>
>>> >> > newBinding]].<br>
>>> >> ><br>
>>> >> > declarations add: binding.<br>
>>> >> > self binding: binding addedTo: self.<br>
>>> >> > ^anObject<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > Could you elaborate a bit please?<br>
>>> >> ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> ><br>
>>> >> >> If the Environment importSelf, then the ClassBinding/Global also<br>
>>> goes<br>
>>> >> >> to<br>
>>> >> >> bindings... (thru an observer pattern and the magic of naming<br>
>>> policies)<br>
>>> >> >><br>
>>> >> >> The bindings is what is used by the compiler, so what if an<br>
>>> environment<br>
>>> >> >> does not importSelf? It means that the variable it declares are<br>
>>> >> >> not<br>
>>> >> >> bound,<br>
>>> >> >> so it is not reachable (kind of invisible class/Global).<br>
>>> >> >><br>
>>> >> >> IOW, the bindings will contain all the imports, including<br>
>>> self-imports.<br>
>>> >> >> importSelf is generally what we want to do, unless weird cases of<br>
>>> >> >> powerless<br>
>>> >> >> environment for obfuscation or trustless sandboxing reason.<br>
>>> >> >><br>
>>> >> >> Now, associationAt: does not speak for itself. It's too hard to<br>
>>> decide<br>
>>> >> >> if<br>
>>> >> >> we're speaking of own declarations or bindings... Analyzing the<br>
>>> usage<br>
>>> >> >> is<br>
>>> >> >> difficult. bindingAt: would be less ambiguous, so IMO we cannot<br>
>>> >> >> fix<br>
>>> >> >> without<br>
>>> >> >> semantic shift.<br>
>>> >> ><br>
>>> >> > This would need as well elaboration as well a separate thread.<br>
>>> >> ><br>
>>> >> ><br>
>>> >> >> The semantic will be carried by the senders (the Tools), and the<br>
>>> tools<br>
>>> >> >> by<br>
>>> >> >> usage we want to make of Environment. So we first have to define<br>
>>> that:<br>
>>> >> >> what<br>
>>> >> >> feature do we want to support? With which tool? That probably<br>
>>> require<br>
>>> >> >> yet<br>
>>> >> >> another thread...<br>
>>> >> ><br>
>>> >> > Yes<br>
>>> >> ><br>
>>> >> > --Hannes<br>
>>> >> ><br>
>>> >><br>
>>> ><br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>