adding a method to a published interface

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

adding a method to a published interface

frank.schoenheit
Hi,

would adding a method to an existing published interface be considered
too incompatible for a 3.2 release?

In particular, css.awt.XView has a method setZoom, but not a getZoom,
which I'd like to add. I could create a crutch called XView2, deriving
from XView, having only this one said method. However, it would lead to
a better API (IMO), if we would simply add the method to XView.

Now XView is "published", but did't we say that there's a certain type
of incompatible API changes which we should consider to allow for
non-major OOo releases?

In this particular case, I'd say this is such a case: The change makes
the interface more consistent, allows retrieving information which
otherwise cannot be retrieved (via UNO), and touches an interfaces which
is rarely used inside OOo's code base (and probably also rarely outside
of it).

Opinions?

Ciao
Frank

x-post to interface-discuss and dev@api, follow-up to dev@api

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [api-dev] adding a method to a published interface

Malte Timmermann
I disagree with doing "selected" enhancements in single css.awt interfaces.

All API in css.awt is "broken", because someone made the decision there
shouldn't be get- methods, because they are "evil".

Some background: - css.awt was one of the first APIs we ever created,
with first version of UNO, and the main intent was a remote client,
where get methods are very expensive, because they can't be called
oneway and would block further program execution until they return.

This is why the API is how it is... :(

If people agree on incompatible changes, I would prefer to clean up all
css.awt API and add missing get- methods.

I wouldn't start to do it "here and there" when somebody stumbles over
it. And the next change, and one change again, one more, ...

But a full cleanup probably really would need to wait for a major
version (and an agreement on incompatible changes).

Malte.

Frank Schönheit - Sun Microsystems Germany wrote, On 06/29/09 12:43:

> Hi,
>
> would adding a method to an existing published interface be considered
> too incompatible for a 3.2 release?
>
> In particular, css.awt.XView has a method setZoom, but not a getZoom,
> which I'd like to add. I could create a crutch called XView2, deriving
> from XView, having only this one said method. However, it would lead to
> a better API (IMO), if we would simply add the method to XView.
>
> Now XView is "published", but did't we say that there's a certain type
> of incompatible API changes which we should consider to allow for
> non-major OOo releases?
>
> In this particular case, I'd say this is such a case: The change makes
> the interface more consistent, allows retrieving information which
> otherwise cannot be retrieved (via UNO), and touches an interfaces which
> is rarely used inside OOo's code base (and probably also rarely outside
> of it).
>
> Opinions?
>
> Ciao
> Frank
>
> x-post to interface-discuss and dev@api, follow-up to dev@api
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]