<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-29 7:33 GMT+02:00 H. Hirzel <span dir="ltr"><<a target="_blank" href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>></span>:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">On 9/28/16, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@<wbr>gmail.com</a>> wrote:<br>
> Since we are at reviewing Environment, here is a small detail that bothers<br>
> me. I already asked some months ago, but silence was the only response, 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 make 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>
</span>Alternatively a description of the general ideas and the mechanism would 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>
<span class="gmail-"><br>
<br></span></blockquote><div>More than that: we only get core functionalities, the intentions are not written here.<br></div><div>IOW things still are very open.<br> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
<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 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 binding to<br>
> bindings).<br>
<br>
</span>Environments<br>
<br>
bind: aSymbol to: anObject<br>
| binding newBinding |<br>
newBinding := aSymbol => anObject.<br></blockquote><div>This creates either a Global or ClassBinding.<br></div><div>The first one is writeable, the second not.<br> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
binding := declarations associationAt: aSymbol ifAbsent: [nil].<br></blockquote><div><div>A class points to its environment where it is declared.<br></div><div>So we expect this invariant:<br></div> (Foo environment declarationOf: Foo name) value == Foo.<br><div>And of course:<br></div><div> (declarations values select: [:c | c isBehavior]) allSatisfy: [:c | c environment == self].<br></div>For globals I don't know why they are attached to a specific environment.<br>Just because of mechanism for propagating changes?<br> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
binding ifNotNil:<br>
[binding class == newBinding class<br>
ifTrue: [binding value: anObject]<br>
ifFalse: [binding becomeForward: newBinding].<br>
^anObject].<br></blockquote><div><br><br></div><div>Since we different binding classes we cannot just change the value.<br></div><div>Since bindings are shared by bindings inst. var., CompiledMethods and other environments if we don't use value, we must preserve identity with a become...<br><br></div><div>Note: above code protects against Object := Array because ClassBinding cannot change value.<br>But not against Object := 1, become protects nothing. It must be handled somewhere else.<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
binding := undeclared associationAt: aSymbol ifAbsent: [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: newBinding]].<br>
<br></blockquote><div>If we previously had some undeclared reference to such variable name (normally a Global with nil value), it's time to rebind it.<br> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
declarations add: binding.<br>
self binding: binding addedTo: self.<br></blockquote><div>Now propagate the change to every interested observer (those who import declarations from yourself). <br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
^anObject<br></blockquote><div>like at:put: used to do, we still answer the put object.<br> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
<br>
Could you elaborate a bit please?<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>See above, by pure reverse engineering ;)</div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
<br>
<br>
<br>
> If the Environment importSelf, then the ClassBinding/Global also goes to<br>
> bindings... (thru an observer pattern and the magic of naming policies)<br>
><br>
> The bindings is what is used by the compiler, so what if an environment<br>
> does not importSelf? It means that the variable it declares are not bound,<br>
> so it is not reachable (kind of invisible class/Global).<br>
><br>
> IOW, the bindings will contain all the imports, including self-imports.<br>
> importSelf is generally what we want to do, unless weird cases of powerless<br>
> environment for obfuscation or trustless sandboxing reason.<br>
><br>
> Now, associationAt: does not speak for itself. It's too hard to decide if<br>
> we're speaking of own declarations or bindings... Analyzing the usage is<br>
> difficult. bindingAt: would be less ambiguous, so IMO we cannot fix without<br>
> semantic shift.<br>
<br>
</span>This would need as well elaboration as well a separate thread.<br>
<span class="gmail-"><br>
<br>
> The semantic will be carried by the senders (the Tools), and the tools by<br>
> usage we want to make of Environment. So we first have to define that: what<br>
> feature do we want to support? With which tool? That probably require yet<br>
> another thread...<br>
<br>
</span>Yes<br></blockquote><div><br></div><div>already opened :)<br> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
--Hannes<br>
<br>
</blockquote></div><br></div></div>