Hi Matthias,
thank you for taking the time for such detailed and elaborated feedback.
Matthias B. wrote:
> How do I fix my extension to work with the new name? It's a plain
> string. There's no refactoring tool that ensures correctness. Search
> and replace on source code is not really a wise idea. Manual review is
> necessary for all occurrences. And how do I make sure I get them all?
> Maybe there's code such as
>
> if (eventName.endsWith("Load"))
>
> I would miss this on my search for "OnLoad". Or maybe the event name
> is converted to lower case before processing? Should I grep for all
> occurrences of "load" (ignoring case) in the code and manually review
> them all? It's a pretty common word
>
> $ grep -ir load .|wc -l
> 6238
>
> in my workspace.
>
> Our extension is 9 lines written by several people over 4 years
> and the event handling code is among the oldest code that we're most
> reluctant to touch.
>
> Then of course there's the issue that we support all versions of OOo
> since 2.0, so we can't just replace occurrences of "OnLoad" with the
> new name. We'll have to change the code to query the OOo version and
> use the appropriate name. That makes the code harder to maintain and
> risks introducing bugs into code that works perfectly.
>
> If you absolutely want to break the events API, then do it properly
> and do away with the use of plain strings as event identifiers and
> replace them with constants/enums.
I don't *want* to break the API, I just considered it as an option here.
But meanwhile I think that keeping the compatibility fallback
"OnLoad/OnOpen" is a small price I'm willing to pay to release API based
developers from the considerable burden to do manual code rework (though
I wonder why someone would use hard-coded strings in his code, but
anayway). I will post more details in another mail.
> Regarding "no commitment to backwards compatibility". This was not
> just about API but about OOo in general. Off-hand I remember 2
> instances when we have had to change our extension because OOo changed
> in an incompatible way. One was the change of the classpath of the
> classloader loading the extension, the other was the URE-separation
> that required the use of new bootstrap code. But I know there was at
> least one other instance. So we have 6 OOo versions (not counting 3rd
> digit versions) released since 2.0 and 3 incompatible changes. That's
> 1 in 2 versions. And the attitude of the developers behind these
> changes is always that it's okay to do this whenever it can improve
> OOo in some way no matter how minor. There definitely is no commitment
> to backwards compatibility as far as I can see. You telling me
> otherwise is like saying "Hey, you should be happy that we don't break
> your extension with *every* new minor version." Well, as a matter of
> fact, if we include unintentional regressions in our count, then you
> do break our extension almost every time you release a new version.
I must confess that I was not aware of the mentioned incompatible
changes at the time where they have been done (and AFAIK they have not
been discussed here). I don't comment on that now, as this would be a
very cheap win, hindsight is always easier than foresight.
> Regarding "just a recompile": This argument to play down the severance
> of an API change makes several assumptions: You're assuming
(...)
- some interesting points snipped -
No, I don't assume anything of that, I try to see it from both sides. I
believe that if when very bad APIs start to hinder further product
development or create quality risks, it should be possible that they can
be changed, even if then some extensions must be recompiled or even
changed. A good example: missing exception specifications that make it
impossible to report errors to the code calling the API.
You might have read in another post from me that I'm not a big friend of
changing APIs just because the result is more "elegant"(*) - but OTOH I
don't want to exclude any API changes in future, because I know that
there are some APIs that are close to unusable. In another posting I
used the unfortunate wording "every API change should be allowed". What
I meant is that I don't want to exclude any possible changes before even
considering them, but in all cases I want to see a justification for the
possible pain they might create. Maybe this procedure even had prevented
the binary incompatibilities you mentioned?!
At the end, we, the OOo developers and people like you, developers
working on top of OOo, are part of a common micro cosmos. We all must
have an interest that it does not "go down the drain" - in all parts,
the central "planet" as well as the "satellites". So some common
understanding and sympathy is needed.
And we should refrain from tempting fate. Let's wait until the suggested
incompatibilities show up and then look at them from all sides.
Regards,
Mathias
(*) I hope that I could make clear that the reason for my event name
chan
