Am 25.08.2004 um 11:00 schrieb Andrew Tween:

> Hi,
> Replacing the default Browser with OmniBrowser *might* make things 
> easier.
> However; the default browser would still need to be available, and if 
> it is
> available then Shout should still work with it.
Replacing. The old browser is a hack and *very* bad for extensions, 
experiments
and stuff like that.

> So, whether the default browser remains part of the image, or is split 
> out
> into a package, the problem of integrating with it remains the same.
> Then there is mvc - I don't know if OmniBrowser works under mvc (or 
> could be
> made to work)??
>
We should realy at one point decide about having one system, why provide
MVC and Morphic? (yes, morphic is too slow... and too big, and 
impossible
to understand). So... not that this helps in this discussion ;-)

> Although I have come up with one solution, for Shout, using 
> AppRegistry,  it
> may not be the best solution.
> We should take some time to consider the options before making changes 
> to
> the kernel.
Yes.

>
> The big danger in all this is that we introduce a framework that leads 
> to as
> many bugs as would be caused by simply allowing packages included in 
> the
> full image to override kernel methods.
>

The danger with overriding not only introduction of bugs: The biggest 
problem
are two clients that change the same method in the image. Both do the 
change
because they want to add certain functionality. So the first override 
works Ok, but
the second one can not work: It undos the changes of the first, this 
braking the
module that depend on that change.

There is the same problem with method additions: If two modules add the 
same
method to the same class, it won't work.
(One could say that modules loose composition semantic as soon as you 
allow overrides).

So overrides are evil. I guess that's why other systems do not allow 
them. But
their are *realy* powerful, and we want them.

There are two interesting ways of dealing with that problem:

1) Make ovverrides local to the module. So a module is free to override 
methods,
      but the system takes care that these are local. That is: when 
calling the method,
      everybody else gets the old one, but the module that did that 
override get the
      new one. This is what Alexandre's ClassBoxes provide.

      This would of couse not solve the problem in the cases were 
overrides are used
      to add functionality to the system as a whole.

2) Ovverrides most of the time just add hooks into the system. If you 
look
     at AOP, that's exactly what these kind of systems provide: They 
allow you
     to hook code into well specified points of your program. The 
interesting thing is
     that these hooks have a composition semantic, so we can have 
multiple clients
     hooking into the same method without interference.

But in the end, there will just be "patches" and "modules", even if the 
modules are
powerful. (classnboxes, AOP). And patches need to be intergrated. There 
can't be
anything done to make this not needed.

> So; we need to make kernel changes; but we need to consider carefully 
> what
> those changes should be.
> If we are aiming to acheive this for 3.9, then there is no great rush.
>
Yes.

       Marcus