Frank Schönheit - Sun Microsystems Germany wrote: > 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.
That sounds reasonable. I also think that we should not hesitate to change unpublished APIs as we see fit. OTOH we should not leave APIs unpublished for such a long time as in case of the one we are talking about. And if we should make it more visible if APIs are unpublished and better and unmistakable explain the consequences for code/extensions using them. As an example, we could mark unpublished stuff in our online documentation and add a very visible hyperlink to it that points to a page explaining all that. So nobody will need to scan the DevGuide just to learn this important peculiarity of our API. BTW: a keyword "unpublished" would come in handy here as it could become the hyperlink itself! It seems we did it the wrong way. Not only because of this but also because (as usual!) not the standard way of doing things (the published API) should be marked by a special attribute, but the one off the road (the unpublished API). Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
