Frank Schönheit - Sun Microsystems Germany wrote: > IRC, you already made another exception in another thread where we > discussed that, namely you agreed that adding non-optional properties to > published services should be allowed.> Using your arguments from above, I > could say that this shouldn't be > allowed, as there could be extensions which implement this service, and > thus we would need to invalidate all existing extensions if we ever add > such a property. Of course this would be nonsense, as an educated guess > would probably tell us that not a single extension in the world exists > which implements this service.
This is an insufficient comparison. I was talking about old style services and you should know that their specification has only documentary purpose. Adding a property here can't break existing code and by adding a "since" tag you can make clear for new code that it must be aware of older implementations not supporting it (means: plan for catching an exception). But anyway, if you feel the need to forbid that also, no problem. > All in all, I am much less pessimistic than you are about the acceptance > of such changes. And that's probably the central question, like with > every change: Would it please more users than it would repel? > > In the concrete case, not repelling users is a matter of having control > over what we do (instead of just allowing any kind of change for any > release), and that's where we disagree: I think we *are* able to retain > that control. > > So how do we proceed? Who's to finally decide that? Exactly this question is the reason why I want to have a "black and white" rule, and it should be simple to apply it. The best I can see so far is: as long as an interface is used or implemented inside OOo, it's possible that changing it can break code. Anything that can break existing code should be possible only in major releases and there should be a good, commonly accepted root cause for the change (changing a single interface just for language esthetical feelings IMHO isn't one of them). Otherwise we will always have lengthy discussions like this one. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
