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

David T. Lewis lewis at mail.msen.com
Thu May 18 23:49:00 UTC 2017


On Fri, May 19, 2017 at 01:46:09AM +0200, Levente Uzonyi wrote:
> 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).
> 

Ah, ok. I did not understand that.

Dave

> Levente
> 
> >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