Hi,
Environment>>associationAt: is part of the Smalltalk globals Dictionary compatibility interface, right? As a quick and dirty fix, I changed instances of Smalltalk at: xyz in Monticello code to CurrentEnvironment signal at: xyz, but #at: also only reads in the declarations, so myEnvironment at: #MCWriter or myEnvironment at: #Object returns nil by default. It would make more sense to perform a full lookup via #valueOf:ifAbsent: in #at: and its cousins, wouldn't it?
Best, Jakob
2016-09-29 7:33 GMT+02:00 H. Hirzel hannes.hirzel@gmail.com:
On 9/28/16, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Since we are at reviewing Environment, here is a small detail that bothers me. I already asked some months ago, but silence was the only response, so ping.
Implementation of Environment is sometimes not obvious:
- Environment>>associationAt: uses declarations inst.var..
- Environment>>associationOrUndeclaredAt: uses bindings inst.var.
How can it be so different, the selector does not speak, does it?
OK, there is a flag: #review in one of them, but that does not make code clearer, it's just a smell of over-complexity or ill-naming.
Whatever the reason (self explaining code?) Colin does not comment class/methods, that's a fact.
Alternatively a description of the general ideas and the mechanism would help.
After all Environments is just a clever combination of a few dictionaries to look up class names? Isn't it? ;-)
However the fact that people did not move on much finalising the implementation of environments since 2012 shows that it is hard to reverse-engineer the intentions from the (incomplete) code.
Chris made the effort of commenting Environment but then came this declarations/bindings split, and the comment did rapidly rot. We have here an un-healthy statu quo crying for change.
So if we want to at least comment the class with the meaning/role/responsibility of inst vars, here is my understanding:
environment bind: #Foo to: 0. just add to the declarations. (You see how names are not obvious: bind does not bind the new binding to bindings).
Environments
bind: aSymbol to: anObject | binding newBinding | newBinding := aSymbol => anObject.
binding := declarations associationAt: aSymbol ifAbsent: [nil]. binding ifNotNil: [binding class == newBinding class ifTrue: [binding value: anObject] ifFalse: [binding becomeForward: newBinding]. ^anObject]. binding := undeclared associationAt: aSymbol ifAbsent: [nil]. binding ifNil: [binding := newBinding] ifNotNil: [undeclared removeKey: aSymbol. binding class == newBinding class ifTrue: [binding value: anObject] ifFalse: [binding becomeForward: newBinding]]. declarations add: binding. self binding: binding addedTo: self. ^anObjectCould you elaborate a bit please?
If the Environment importSelf, then the ClassBinding/Global also goes to bindings... (thru an observer pattern and the magic of naming policies)
The bindings is what is used by the compiler, so what if an environment does not importSelf? It means that the variable it declares are not bound, so it is not reachable (kind of invisible class/Global).
IOW, the bindings will contain all the imports, including self-imports. importSelf is generally what we want to do, unless weird cases of powerless environment for obfuscation or trustless sandboxing reason.
Now, associationAt: does not speak for itself. It's too hard to decide if we're speaking of own declarations or bindings... Analyzing the usage is difficult. bindingAt: would be less ambiguous, so IMO we cannot fix without semantic shift.
This would need as well elaboration as well a separate thread.
The semantic will be carried by the senders (the Tools), and the tools by usage we want to make of Environment. So we first have to define that: what feature do we want to support? With which tool? That probably require yet another thread...
Yes
--Hannes
2016-09-29 15:15 GMT+02:00 Jakob Reschke jakob.reschke@student.hpi.de:
Hi,
Environment>>associationAt: is part of the Smalltalk globals Dictionary compatibility interface, right? As a quick and dirty fix, I changed instances of Smalltalk at: xyz in Monticello code to CurrentEnvironment signal at: xyz, but #at: also only reads in the declarations, so myEnvironment at: #MCWriter or myEnvironment at: #Object returns nil by default. It would make more sense to perform a full lookup via #valueOf:ifAbsent: in #at: and its cousins, wouldn't it?
Best, Jakob
I imagine that the question is about tools. For now Smalltalk importSelf, so bindings and declarations do agree. 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? 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. There is no easy solution. A single facade for two dictionaries cannot fit all, so we need several different messages. But it's much about what we want to do with those environments.
2016-09-29 7:33 GMT+02:00 H. Hirzel hannes.hirzel@gmail.com:
On 9/28/16, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Since we are at reviewing Environment, here is a small detail that
bothers
me. I already asked some months ago, but silence was the only response,
so
ping.
Implementation of Environment is sometimes not obvious:
- Environment>>associationAt: uses declarations inst.var..
- Environment>>associationOrUndeclaredAt: uses bindings inst.var.
How can it be so different, the selector does not speak, does it?
OK, there is a flag: #review in one of them, but that does not make code clearer, it's just a smell of over-complexity or ill-naming.
Whatever the reason (self explaining code?) Colin does not comment class/methods, that's a fact.
Alternatively a description of the general ideas and the mechanism would
help.
After all Environments is just a clever combination of a few dictionaries to look up class names? Isn't it? ;-)
However the fact that people did not move on much finalising the implementation of environments since 2012 shows that it is hard to reverse-engineer the intentions from the (incomplete) code.
Chris made the effort of commenting Environment but then came this declarations/bindings split, and the comment did rapidly rot. We have here an un-healthy statu quo crying for change.
So if we want to at least comment the class with the meaning/role/responsibility of inst vars, here is my understanding:
environment bind: #Foo to: 0. just add to the declarations. (You see how names are not obvious: bind does not bind the new binding
to
bindings).
Environments
bind: aSymbol to: anObject | binding newBinding | newBinding := aSymbol => anObject.
binding := declarations associationAt: aSymbol ifAbsent: [nil]. binding ifNotNil: [binding class == newBinding class ifTrue: [binding value: anObject] ifFalse: [binding becomeForward: newBinding]. ^anObject]. binding := undeclared associationAt: aSymbol ifAbsent: [nil]. binding ifNil: [binding := newBinding] ifNotNil: [undeclared removeKey: aSymbol. binding class == newBinding class ifTrue: [binding value: anObject] ifFalse: [binding becomeForward:newBinding]].
declarations add: binding. self binding: binding addedTo: self. ^anObjectCould you elaborate a bit please?
If the Environment importSelf, then the ClassBinding/Global also goes to bindings... (thru an observer pattern and the magic of naming policies)
The bindings is what is used by the compiler, so what if an environment does not importSelf? It means that the variable it declares are not
bound,
so it is not reachable (kind of invisible class/Global).
IOW, the bindings will contain all the imports, including self-imports. importSelf is generally what we want to do, unless weird cases of
powerless
environment for obfuscation or trustless sandboxing reason.
Now, associationAt: does not speak for itself. It's too hard to decide
if
we're speaking of own declarations or bindings... Analyzing the usage is difficult. bindingAt: would be less ambiguous, so IMO we cannot fix
without
semantic shift.
This would need as well elaboration as well a separate thread.
The semantic will be carried by the senders (the Tools), and the tools
by
usage we want to make of Environment. So we first have to define that:
what
feature do we want to support? With which tool? That probably require
yet
another thread...
Yes
--Hannes
squeak-dev@lists.squeakfoundation.org
-
Jakob Reschke -
Nicolas Cellier