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.


- Frank Schönheit, Software Engineer         frank.schoenh...@sun.com -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org

Reply via email to