Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> Anthony Hannan <ajh18 at cornell.edu> wrote:
> > [snip] But more importantly, you can no
> > longer find all senders and implementors of a class/method.
> So we need extended tools for this. We needed extended tools in the
> first place to even have the concept of looking for senders/etc by means
> other than grep.

Well, I want these tools before removals go into the update stream.  Can
I get real updates while bypassing the removal updates?

> > This makes
> > it hard to confidently make changes since you can no longer see all
> > dependent code.  With a full image, I find all dependent code and make
> > changes accordingly.  This allows me to make wholesale changes,
> > confidently.  I wouldn't be able to build a robust closure compiler if I
> > didn't have Etoys, MessageTally, ProcessBrowser, ImageSegments, etc.
> > loaded because I wouldn't know to update them to work correctly with the
> > new closure compiler.
> Which implies to me that a lot of stuff was poorly written to
> improperly depend on things it shouldn't.

Not always.  Etoys rightly depends on the compiler parse nodes to tile
parse trees.  If I change these parse nodes I want to know who uses them
so I can change them accordingly.

> > I do agree we need modules in the image to better structure our code,
> > but the modules should all be in the same image so we can see all
> > dependents (to confidently make changes).
> Load them all and they will all be there.

If I load them all I may get conflicts.  That is why we need real
modules.  Again I want this before things are removed.

> A distributed image than loads what it needs when it needs it is a
> lovely idea (and one I was proposing to Esprit committees over ten years
> ago for research funding) but requires reliable, secure, fast, pervasive
> connectivity. The world is certainly moving towards that capability but
> it isn't there yet and it doesn't help anywhere near all use cases so we
> cannot have a design that only works that way.

I understand that.  I didn't go into details.  A client machine in a
distributed image would download what it anticipates will be needed,
maybe with some choices made by the user.  Distributed-image achieves
the what-you-need-is-what-you-get (WYNIWYG) goal and has several
advantages over build-what-you-need-from-packages.  They are:
1. It separates the module concern from the WYNIWYG concern.  Even
though the two can overlap, they are not the same concept and should not
be modeled as one.  Besides you may need other things besides module
code, like morphs, projects, etc., also you may not need all the code in
a module.
2. Syncronization.  Object know where they came from and can be
automatically updated if changed remotely.  Images built from packages
don't know where they came from so can't be updated automatically,
unless some package update mechanism is built.  But building this
update mechanism into objects (for distributed image) instead of
packages allows us to reuse it for real-time collaborative computing (a
la Croquet).

Cheers,
Anthony