On Thu, May 18, 2017 at 10:57:37PM +0200, Nicolas Cellier wrote:
> 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.

Using #allInstancesDo: is not ugly, it is just inefficient. That means we
can safely optimize it later when the need arises.

Whenever someone actually has a multi-gigabyte image that actually uses
Environments in some meaningful way, that person will probably have a better
idea of how and why the organization should be set up. Until then there is
no real problem to be solved, and no need to restrict how the organization
of Environments within an image should work.

$0.02,

Dave