adding a method to a published interface

View: New views
2 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

Re: adding a method to a published interface

by Mathias Bauer :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Mathias,
>
>>> Which really also might turn out as "never" - the unlikeliness of
>>> the big-bang-change to happen was already pointed out (since when
>>> are we talking about awt redesign? I personally think it's >8 years
>>> now).
>>
>> If it doesn't happen, the pain to have them obviously is not big enough.
>> If it hurts you that much, go on and make the change.
>
> Sorry, but that's nonsense.

No, seriously: if we still don't start changing this and instead of this
do other things, then obviously the pain is not big enough to overcome
the pain we feel in the other areas we are working. "Pain" isn't
absolute here, it's always in relation to something else and to the
relecance that the different parts have for the whole project.

> How many years do we talk about a new resource system? How many pain did
> it cause in the last 20 years that dialogs are developed by hacking a
> text file, instead of some decent UI editor? How many man *years* have
> been wasted by this? And what happened to ease that pain? Nothing at all!

Maybe because other pain was bigger? Maybe because those feeling the
pain didn't explain it good enough? Fact is, that everybody (including
yourself) did something else. That means to me: other things have been
more important.

You won't change that by breaking a single interface. This will not
remove the "pain" you have described.

So I repeat my point: if re-working awt is important enough (and a
general agreement about that exists), it should be done. Fixing a single
interface is pointless and should be avoided.

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: adding a method to a published interface

by Mathias Bauer :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

< Prev | 1 - 2 | Next >