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).


Mathias Bauer (mba) - Project Lead Writer Engineering at Sun:
Please don't reply to "".
I use it for the OOo lists and only rarely read other mails sent to it.

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to