Hi Ariel, first: no offense intended with my mail. I perfectly understand the difficulties of extending an existing ... suboptimal API ...
> "There is one problem with your > solution, I don't want that we change an interface (XMenuExtended) > incompatible which has been available since four years. Although it's > not published yet changing it would be a bad signal for developers who > already use the interface. Therefore, from my point of view, the only > solution would be to add a new interface providing access to images." uhm - in my opinion, this makes the "published" concept absurd. If we say a published interfaces cannot be changed, but unpublished ones can, but then don't dare to do the latter ... then just let's say "Never change an interface". That's far easier. And no, this is no serious suggestion. I suppose my attitude towards API changes is well known, so I won't start this from the ground here. That's the long-promised responsibility of Jürgen :) In this particular case, one has to ask which problems existing users of this interface would have, if we would add a new base interface, and some new methods. For Basic users, it doesn't matter. For Java clients, it's about re-compilation, at most. For Java implementors (highly unlikely), its about adding new methods to their implementation. For C++, the situation is the same as for Java. So, considering this, I think the "expected grief" for developers using this interface is nearly 0. >> (And while we are at it ... is it just me as non-native English speaker >> who thinks that "XFooExtended" sounds like ... well, non-native English >> speakers creating API names? XExtendedFoo, or XFooExtension, or XFoo2, >> or ... but "XFooExtended"?) > > yes, there is the (deprecated) XExtendedToolkit. I just followed the > XMenuExtended naming scheme, as it wouldn't make any sense to name > XExtendedMenu2 with a XMenuExtended, so I also named XPopupMenuExtended, > XMenuBarExtended. Well understood. This doesn't make it sound better :) > The awt module is just a reflection of the global situation in OOo API, or > how > do we interpret things like css.ucb.XSimpleFIleAccess/2/3 ... n? When will it > stop? when they reach XSimpleFileAccess30? Well, above, you cited Carsten who argued for making the API uglier (yes!) for the sake of (questionable, in this case at least) API stability. Here, you complain (rightfully) about ugly APIs. You know, the APIs you just created (no offense intended) will be next year's example for ugly APIs :) Means: If existing API is unpublished, then IMO we should extend it incompatibly, if it becomes a little better / less ugly thereby .... > Of course css.ucb.SimpleFIleAccess/XSimpleFileAccess cannot be changed > because > they are published, the same goes for css.awt.X/PopupMenu and > css.awt.X/MenuBar, so IMHO the published/unpublished concept should be > redesign. No, you won't get me in joining this discussion here. But you're absolutely right :) 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
