Hi Malte, > I didn't say I want to stay w/o getter methods, but that I want to > introduce them. But then not just in that one place, because I remember > that people complained about missing getter methods in many AWT interfaces. > > So my point was to introduce them in all AWT interfaces where they are > missing, and not step by step. > > (A completely different/better AWT API would be an other discussion - > nothing for now)
okay, I see your point here. Do you have a list of all those missing getter methods? I am not completely convinced it makes sense do introduce all getters at once, but it's definitely worth a consideration. I might be willing to do this, as long as it's consistently possible. That is, the proposed XView change is easy, because this interface is implemented once in OOo, and most probably nowhere else. Also, no other interface derives from it, so that we really have a very isolated source of potential problems, which we should be able to control. This might not be true for all other methods which need getters. So, if this turns out to be too much effort (means I simply do not have/get the time for this), then I would still argue for a lot of small steps which actually happen, than a little big step which never happens at all. XView::getZoom is a problem I have *now*. > As long as we don't do it consequently, then the X<something>2 approach > might be better for now, as it seems we already did with XWindow2. I disagree. I don't see any convincing argument for XSomething2, except preserving compatibility. If this is not an issue (such as for XView), then XSomething2 just adds to API clutter, and makes the API even less appealing for users to work with. And it is my strong believe that we need every single API developer, to make them create OOo based content to ensure OOo's success on the long run. > I think it's better to break AWT API compatibility once, instead of many > times in many releases. I think that absolute rules such as those do not make sense, but one needs to investigate and judge every single case, guided by a set of rules. Yes, we didn't define this rule set, yes. But that's not really a problem, the evolutionary approach might work well here. I'm just trying to add a tiny piece to the set: "For a rarely-implemented interface, adding a method needed for completeness and consistency is allowed even in minor versions". > If people want to spread API changes over multiple releases, we would > need to clarify in advance that API compatibility is nothing we want to > take care for anymore in general - and not doing exceptions on > discussion basis every time. As said, not based on discussions, but based on a rule set. As I see it, an inevitable precondition for this rule set is discussion. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
