[squeak-dev] The Inbox: System-jr.948.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu May 18 20:57:37 UTC 2017


2017-05-18 22:43 GMT+02:00 Jakob Reschke <jakob.reschke at student.hpi.de>:

> 2017-05-17 1:23 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> > Surely an Environment is installed in some other environment, much like a
> > class being installed in its superclass, and hence being present in its
> > superclass's subclasses array.
>
> A fresh Environment is completely isolated. It has no connection to
> the original Smalltalk globals environment (except via its own class,
> or when you put a class in it manually you may navigate to another
> environment via the superclass, but Environment does not know about
> that). It only gets connected with other environments when you import
> something in either direction.
>
> Accessing the upstream and downstream connected environments of a
> given Environment would currently involve poking around the
> 'observers' and 'policies' instance variables. No useful accessors for
> navigation yet, because these connections are designed to propagate
> the updates of bindings, not to navigate the system.
>
> > So if an Environment is always in relation to the root environment, and
> > environments refer to those that they contain, all installed environments
> > can be enumerated from the root, touching a small fraction of the entire
> > object graph, unlike allInstancesDo: which visits every object in the
> heap.
>
> There is no explicit hierarchy, but one could start from Smalltalk
> globals (or everything in the Instances class variable) and search the
> graph of observers (approximately: importers). However, this might not
> find strictly *all* implementors and senders in the object memory,
> contrary to what the message names #allImplementorsOf: and friends
> suggest, or what might be expected from the search box.
>
> Comments? Better ideas? I would not like to implement this if there
> are serious objections to the approach from the beginning.
>
>
Since all classes have 1 defining environment, maybe walking the whole
class hierarchy will enable collecting environments.
The chicken and egg problem is how we would find the root classes (those
with nil superclass)?
...by scanning all the classes of an environment... For now we do not have
so many roots, but who knows...

Of course, there could be environment that define no classes but just alias
and over "globals" (static variables), but if the goal is to scan all
classes, we don't care of those.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170518/b198b552/attachment.html>


More information about the Squeak-dev mailing list