Le 30/05/2013 14:27, Marcus Denker a écrit :
On May 30, 2013, at 2:22 PM, Goubier Thierry <[email protected]> wrote:
Le 30/05/2013 14:09, Stéphane Ducasse a écrit :
On May 30, 2
Yes. I can say true become: false, too.
Overrides can be interesting as a temperer hack. E.g. in Opal development, I
might add an override just to test. Then loading Opal makes
the image package dirty. So later, when I know what I want, I will move that
change to the image.
You should not use overrides as a concept in delivered software (as it does not
work), so modeling it is wrong as then people will use it.
Yes making it impossible is not nice either, because temporarily I want to be
able to just do it, like I can do all sorts of things.
So this is more something we should add a rule for in Code Crititque…
I'm not sure. Because something you really need them.
I'd be worried then.
Either we have a need for extension where only an override will do... Then why
not modeling it and critique it when appropriate? Hiding it under an extension
won't make the problem disappear, it will just hide it.
But it just does not work: two overrides. Which will be called? Overrides are
like halt: you use is while developing and for hacks, but shipped packages just
can not use it, because there is just no semantic
of multiple overrides.
I don't see the point. Overrides are not an executable concept, they are
a package management concept. At execution, only methods do exist. How
two overrides (or even one method and one override) work are the duty of
the package management system. If the package management system forbid
loading two overrides, it's fine by me. If, as an integrator, you reject
any fix with an override, its fine by me. If you decide to let it pass,
then its fine by me too ;)
What I don't like is, we have a way to say we are hacking into the
system in a not so nice way to hook somethin. It's bad, it looks bad,
but it's documented and appears as such. Now, hiding it as an extension
is making a lot worse: it's an override, we can do it, and its hidden
unless you chase the package which changed when it shouldn't (and in
some cases, like loading a package with an hidden override in an image
with unsaved changes can make the search for it an interesting task...)
The only solution is to have system where extensions are private to you, but than the
normal use case for overrides is to "hook into something".
An override is a hook when the underlying system you hook into wasn't
planned to be used that way. Which I say is probably a sign of bad design :(
Maybe something on the sub-method level? Packages could register methods to be
called before and after like in CLOS…
This looks really complex. We have a lot of reflective features
available to allow for nice hooks (flags and just plain subclass queries
as in Monticello repositories), no need to think about how to make
clever overrides (Unless you want to make a paper and get it into, say,
Scala :)).
But as I said: my brain is full. I just can't think about it now.
But I'm enjoying that :)
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
