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

Levente Uzonyi leves at caesar.elte.hu
Thu May 18 23:46:09 UTC 2017

On Thu, 18 May 2017, David T. Lewis wrote:

> 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

You don't have to use Environments to be affected by the change. It's 
enough if you use SystemNavigation (senders, implementors, etc).


> 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

More information about the Squeak-dev mailing list