Lessons learnt from been an integrator
Marcus Denker
denker at iam.unibe.ch
Wed Aug 25 09:58:39 UTC 2004
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
More information about the Squeak-dev
mailing list
|