Dan Ingalls <Dan.Ingalls at disney.com> wrote:

> Well, using the structures of Squeak as they exist (recall I said this
ought to be a 1-week project, and we're already into the second day),
class String either has or does not have a method for asHtml.  If it
does, then it will understand it no matter who calls it.  If it does
not, then it will get a dNU (doesNotUnderstand:) exception no matter who
calls it.
> 
> I can only see two approaches to this.  The first is the static
approach that I have already outlined for projects -- ie when you enter
a project, all changes are asserted, and the system runs that way until
you leave the project.
> 
> The second is a dynamic mechanism that would trap all accesses to any
altered method, vectoring execution to alternate methods depending on
the environment from which the message is being sent.  This mechanism
would introduce a layer of simulation into the execution of any method
that is added, removed, or altered in the base classes.
> 

> Does anyone know of a better solution to the problem (including "Just
say no" ;-)?
> 
> If the general practice is to minimize changes to base classes, then
notification of overlap plus VW's "last loaded wins" is probably
adequate.
> 


This seems fine to me.  I think it's nice having, for instance, an
#asUrl method on String, and moving that method to a utility class
somewhere would be a concession of convenience.  Even bothering with the
notification doesn't seem that critical to me, so long as people name
their methods reasonably.

As a small addition, it would be nice if there is a way for one package
to declare that it needs access to the side effects of certain other
packages, even though it might never reference that package directly. 
If each package has a list of prerequisites, then that would do the
trick just fine.


Lex