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 d...@api, follow-up to d...@api > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
