> if we add an environment variable to CompiledMethods ( or a
> subclass which can
> be used by recompiling all methods in the system ) then you have
> a mechanism to
> keep track of which methods in a given class are "native", and
> which ones are
> really there because some other module wanted them there.  This
> would be a
> crutch- I am not seriously suggesting this as a long term
> solution.  Perhaps it
> is, but I don't have any insight to that at this stage.  But if
> you did this,
> and had the tools to help you discern whether a given method
> belonged to the
> module in which its class is defined, or should instead be listed as an
> extension method provided by another module, I think you could
> get rolling
> relatively quickly.  You would have to be tolerant of the Old
> Reliable tools
> creating these new CompiledMethods without giving them a
> reference to a module,
> but that would be easy to accomodate with the new tools.


	Sounds like what ENVY does with applications, is that what you mean ?
Applications in ENVY define new classes but also class extensions, which are
basically methods to existing classes (methods to classes in the pre-req
graph).


marcio