<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-29 15:15 GMT+02:00 Jakob Reschke <span dir="ltr"><<a href="mailto:jakob.reschke@student.hpi.de" target="_blank">jakob.reschke@student.hpi.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Environment>>associationAt: is part of the Smalltalk globals<br>
Dictionary compatibility interface, right? As a quick and dirty fix, 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>
<span class=""><br></span></blockquote><div><br></div><div>I imagine that the question is about tools.<br></div><div>For now Smalltalk importSelf, so bindings and declarations do agree.<br></div><div>If an Environment does not importSelf, then some variables will be invisibles (unbounds). Do we still want to see them in some tool, or not?<br></div><div>What's going on if we play with Alias? Do we want to see the Alias in some browser? If not, then we'd better stick with declarations.<br></div><div>There is no easy solution. A single facade for two dictionaries cannot fit all, so we need several different messages.<br></div><div>But it's much about what we want to do with those environments.<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
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>> wrote:<br>
</span><span class="">>> 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><span class="">> 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>
><br>
><br>
><br>
><br>
><br>
</span><span class="">>> 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><span class="">> Environments<br>
><br>
> bind: aSymbol to: anObject<br>
> | binding newBinding |<br>
> newBinding := aSymbol => anObject.<br>
><br>
> binding := declarations associationAt: aSymbol ifAbsent: [nil].<br>
> binding ifNotNil:<br>
> [binding class == newBinding class<br>
> ifTrue: [binding value: anObject]<br>
> ifFalse: [binding becomeForward: newBinding].<br>
> ^anObject].<br>
><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>
> 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>
</span><span class="">>> 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><span class="">> This would need as well elaboration as well a separate thread.<br>
><br>
><br>
</span><span class="">>> 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>
><br>
> --Hannes<br>
><br>
<br>
</blockquote></div><br></div></div>