"Pennell, David" <<dpennell at quallaby.com> wrote...

>A related issue is supporting "base class changes".  I know its

>controversial in some quarters, but it certainly is common for

>packages to add a method here and there to Object,UndefinedObject,

>String, etc.  This also has implications in the browsers.


This is a tough one.  I can see how to handle it for internal access.
Our plan for this is to tap into the "isolated projects" mechanism that
I proposed way back and Ted implemented last spring.  The idea is that
changes to system classes get asserted and retracted when you
enter/leave a project.  This is one of the things that works nicely
when packages are identified with projects.


The problem comes when several packages make simultaneous changes to
the base system.  In this case it becomes overly complex to manage
assertion and retraction.  You can deal with it stylistically (don't
change the base classes (or almost never)) and/or administratively
(declare such changes and warn of any conflicts).


If I had to call this right now, I would prohibit packages from making
any changes outside their own scope but I would allow projects to have
attached changes that would be asserted and retracted according to the
current isolated projects mechanism.


I could imagine a hybrid form of use evolving, where someone writes a
big package like T-gen as a project with changes to the base system,
and then clients access it through a protocol that asserts those
changes for the duration of that access, but this just increases the
use of something I don't really like.


Can anyone suggest a better approach to this?


	- Dan