Frank Schönheit - Sun Microsystems Germany wrote:
Hi Ariel,
Means: If existing API is unpublished, then IMO we should extend it
incompatibly, if it becomes a little better / less ugly thereby ....
I've found no way to change its ugliness without breaking API design rules.
Don't know what you have in mind.
Yes, doing it "completely right" is impossible without breaking rules. I
just suggest to make use of the fact that XMenuExtended is not yet
published, and merge everything from XMenuExtended2 into XMenuExtended.
This would get us rid of at least one "2" interface.
If one really has a lot of time, I would take this opportunity to rename
XMenuExtended to XExtendedMenu (or "XMenu2" :), since this still sounds
like a strange name to me.
Of course, if I were left at my own will, I would add every method to XMenu
(common to PopupMenu and MenuBar) and XPopupMenu.
And it *can* even be discussed if css.awt.MenuBar and css.awt.PopupMenu are
*really* published:
Technically, they are, and I am not sure making exceptions here is good.
I'd prefer this problem being solved in general. And the problem here,
as in many other places, is that an old-style service, which effectively
describes an *implementation* (rather than an abstract contract), must
be able to be adjusted to properly describe the evolving implementation.
Hi Frank, Juergen and Ariel,
Unfortunately I missed this discussion thread. Late but I hope not too
late I want to give you my reasons why I decided that Ariel should
create a new interface instead of changing an unpublished one. From my
point of view it's definitely not a solution to change an interface
incompatible which is more than 5 years old (even if it unpublished
which has other reasons). Second, we are now between 3.0 and 3.1 and I
cannot accept to change an interface incompatible between minors. That's
a bad signal to extension developers. Personally I don't like the
Firefox concept which is very relaxed to interface changes. Even between
minor updates sometimes add-ons cannot be used anymore. That's pretty
annoying for users and developers.
It was planned to publish all UNO AWT and new framework interfaces for
the OOo 3.0 release. Unfortunately I was busy with other important
tasks. Therefore I missed to publish these interfaces. I agree that it's
absolutely necessary to have a more flexible approach for changing
interfaces (even published ones). There should be a discussion between
OOo developers what level of flexibility is necessary. Personally I
would propose to change interfaces (even published ones) between major
versions only. It should be clear that more flexibility means
automatically more work to do.
Regards,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
