[squeak-dev] Environment declarations vs bindings

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Sep 29 17:10:24 UTC 2016


2016-09-29 18:39 GMT+02:00 Jakob Reschke <jakob.reschke at student.hpi.de>:

> Many questions should be answered with tooling here, but in the
> particular case I mentioned, IMHO it is not about tooling. Until now,
> code that does `Smalltalk at: something` wants to look up something
> dynamically or it can't be sure that this class is actually loaded. As
> there was only one place to do such lookups, no differentiation about
> visibility or the source of a binding was necessary.
>
> Instances of `Smalltalk at: something` should either be replaced by an
> environment aware equivalent that makes clear if a name should be
> looked up *only* in the receiving environment (in its declarations),
> or if a name should be resolved, looking also in imported environments
> (in the bindings).


Agree


> As it is inconvenient to find all these pieces of
> code and change them all, `Smalltalk (globals)` could be the "active"
> environment (currently via dynamic scoping with `on:
> CurrentEnvironment do: ...`), not the original global environment.


I don't like the idea of CurrentEnvironment at all. IMO global state stinks.
It would mean that a lotta behavior would change by simply switching one
shared variable...
I see it more like a not so clever workaround to make tools still work in
presence of environments with minimal changes.



> But
> then Environment>>at: must behave sensibly. I would expect that I can
> always do `Smalltalk at: #Object` to retrieve `Object` in any
> environment (under the assumption that every environment would import
> the "Kernel" or original environment). This is currently not the case,
> because Environment>>at: looks only into an environment's (own)
> declarations, not the imported bindings.
>
>
I don't know. Maybe (Smalltalk at: #Foo) is questionable by itself.
VW did introduce #{Foo} ifPresent: [:foo | ] or something like that for
deferred bindings.
I remind you that Smalltalk itself is a global variable created with a
different instance for each environment.

Object is in the superclass chain, so we can still access with superclass
superclass ... environment.



> 2016-09-29 17:30 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
> >
> >
> > 2016-09-29 15:15 GMT+02:00 Jakob Reschke <jakob.reschke at 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 at gmail.com>:
> >> > On 9/28/16, Nicolas Cellier <nicolas.cellier.aka.nice at 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.
> >> >         ^anObject
> >> >
> >> >
> >> > Could 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
> >> >
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160929/e2b94aa4/attachment.htm


More information about the Squeak-dev mailing list