Hello Frank,

On Sunday 18 January 2009 17:08, Frank Schönheit - Sun Microsystems Germany 
> 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 :)

haha! I don't feel offended at all, because I was the first to tell myself how 
ugly it is (back in September 2008 

> 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.
Besides, even if methods were added to the "only" unpublished interface, 
XMenuExtended, there will be methods that can not be added here becasue they 
are PopupMenu specifics (not common to PopupMenu and MenuBar); this means that 
a XPopupMenuExtended is still needed.

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: do not forget they were added after I open issues


I doubt to name they "published" (the time I submited that issues, the only 
place in OOo source code that used the service name was in the form image 
control's context menu, even the SDK gui examples use/d the stardiv.... impl. 

Ariel Constenla-Haile
La Plata, Argentina

"Aus der Kriegsschule des Lebens
                - Was mich nicht umbringt,
        macht mich härter."
                Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.

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

Reply via email to