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. Ciao Frank -- - 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
