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         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[Ariel Constenla-Haile]

Hello Frank,

On Monday 29 June 2009, 07:43, Frank Schönheit - Sun Microsystems Germany
wrote:

> 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?

was there an agreement on that? I didn't have time to understand the reasons
given for adding a FilterOperator2, carrying with it a TableFilterField2 and a
XSheetFilterDescriptor2; but the names just tell me there was no agreement.


Regards
--
Ariel Constenla-Haile
La Plata, Argentina

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

[Juergen Schmidt-3]

Ariel Constenla-Haile wrote:

> Hello Frank,
>
> On Monday 29 June 2009, 07:43, Frank Schönheit - Sun Microsystems Germany
> wrote:
>> 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?

to make it short, i would support you to add it. If we make the change
we should start with a new wiki page to document the change and a
migration path even if it would be trivial.

>
> was there an agreement on that? I didn't have time to understand the reasons
> given for adding a FilterOperator2, carrying with it a TableFilterField2 and a
> XSheetFilterDescriptor2; but the names just tell me there was no agreement.
>
I think that there was an agreement to allow incompatible changes for
major releases. And we talked about some specific changes that might be
also allowed for minor releases. But this changes are not yet defined in
detail... Adding a method to an existing interface as Frank suggested
would be of course such a change. No influence on Basic or other
languages using invocation. Only build incompatible in C++ as long as
you don't implement the interface on your own...

Juergen

>
> Regards


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

[frank.schoenheit]

Juergen, Ariel,

> to make it short, i would support you to add it. If we make the change
> we should start with a new wiki page to document the change and a
> migration path even if it would be trivial.

okay. What location do you suggest? Do we already have an entry point in
the wiki to the overall topic "incompatible API changes"?

>> was there an agreement on that? I didn't have time to understand the reasons
>> given for adding a FilterOperator2, carrying with it a TableFilterField2 and a
>> XSheetFilterDescriptor2; but the names just tell me there was no agreement.
>>
> I think that there was an agreement to allow incompatible changes for
> major releases.

Yes.

> And we talked about some specific changes that might be
> also allowed for minor releases. But this changes are not yet defined in
> detail...

And that's what I'm trying to find out - where's the line to be drawn
between "allowed for majors only" and "allowed for minors, too". We
already agreed that making optional properties on old-style services
non-optional is below that line, i.e. allowed for minors.

> Adding a method to an existing interface as Frank suggested
> would be of course such a change. No influence on Basic or other
> languages using invocation. Only build incompatible in C++ as long as
> you don't implement the interface on your own...

The "as long as" is the tricky part in such cases. For instance,
grokking for XView gave me implementations of this interface in the
presenter console, which is delivered as a C++ extension. So, in such a
case, I would have a hard time arguing that adding a method is no
problem at all. Luckily, this was css.frame.XView, not css.awt.XView :)

The given XView interface is effectively *only* implemented in the
toolkit module, and chances that it's implemented outside the OOo code
base are rather low (since all the code around it does not really allow
for pure UNO components outside the OOo code, but that's another topic).
So, I'd say we're on the safe side here.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[frank.schoenheit]

Hi Ariel,

> I didn't have time to understand the reasons
> given for adding a FilterOperator2, carrying with it a TableFilterField2 and a
> XSheetFilterDescriptor2; but the names just tell me there was no agreement.

Well, the agreement really was that for a major release, any API changes
can be done (if well-justified, having a migration path, and the like).
For a minor release, only a certain class of changes can be done, but
this class is not yet defined (see my other mail). Obviously, the
*Filter*2 API was not considered to fit into that class. The most
convincing argument I heard came from Eike:

> If I understood correctly back years ago, changing an enum is not
> possible because in Java there is the Enum object that bails out if the
> value encountered during runtime doesn't match the set declared at
> compile time. Someone correct me if I'm wrong on this or there are
> details to add.

Not sure if this still holds nowadays (my understanding always was it
doesn't), but I didn't try.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[Juergen Schmidt-3]

Frank Schönheit - Sun Microsystems Germany wrote:
> Juergen, Ariel,
>
>> to make it short, i would support you to add it. If we make the change
>> we should start with a new wiki page to document the change and a
>> migration path even if it would be trivial.
>
> okay. What location do you suggest? Do we already have an entry point in
> the wiki to the overall topic "incompatible API changes"?
ooh, we have
http://wiki.services.openoffice.org/wiki/API/Concepts_API_changes which
is currently empty and where i wanted summarize and document the outcome
of our discussions :-(

I would suggest
http://wiki.services.openoffice.org/wiki/API/Changes with a display title

{{DISPLAYTITLE:Incompatible API changes}}
...
* API changes in OpenOffice.org 3.2
<DPL>category=APIChanges_v3.2</DPL>
...
[[Category:API]]
[[Category:APIChanges]]


And for your specific change
http://wiki.services.openoffice.org/wiki/API/Changes/css_awt_XView
{{DISPLAYTITLE:Incompatible API change of com.suns.star.awt.XView}}
...
[[Category:API]]
[[Category:APIChanges]]
[[Category:APIChanges_v3.2]]

With a specific category for each version we can easy collect a list of
all API changes for a specific version and with the general APIChanges
category we can collect all API changes...

It's a quick idea to put the whole stuff in some organized structure.
What do you think?

>
>>> was there an agreement on that? I didn't have time to understand the reasons
>>> given for adding a FilterOperator2, carrying with it a TableFilterField2 and a
>>> XSheetFilterDescriptor2; but the names just tell me there was no agreement.
>>>
>> I think that there was an agreement to allow incompatible changes for
>> major releases.
>
> Yes.
>
>> And we talked about some specific changes that might be
>> also allowed for minor releases. But this changes are not yet defined in
>> detail...
>
> And that's what I'm trying to find out - where's the line to be drawn
> between "allowed for majors only" and "allowed for minors, too". We
> already agreed that making optional properties on old-style services
> non-optional is below that line, i.e. allowed for minors.
>
>> Adding a method to an existing interface as Frank suggested
>> would be of course such a change. No influence on Basic or other
>> languages using invocation. Only build incompatible in C++ as long as
>> you don't implement the interface on your own...
>
> The "as long as" is the tricky part in such cases. For instance,
> grokking for XView gave me implementations of this interface in the
> presenter console, which is delivered as a C++ extension. So, in such a
> case, I would have a hard time arguing that adding a method is no
> problem at all. Luckily, this was css.frame.XView, not css.awt.XView :)
>
> The given XView interface is effectively *only* implemented in the
> toolkit module, and chances that it's implemented outside the OOo code
> base are rather low (since all the code around it does not really allow
> for pure UNO components outside the OOo code, but that's another topic).
> So, I'd say we're on the safe side here.

i agree that we are probably safe here. But it shows also that a general
rule is or can be problematic. Whereas a change like yours is probably
harmless other changes of the same category can break many external
solutions depending on the usage of the changed interface. That is the
reason why we should discuss the changes in public and find a common
agreement for the proposed changes...

Juergen

>
> Ciao
> Frank
>


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

[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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[frank.schoenheit]

Hi Malte,

> I disagree with doing "selected" enhancements in single css.awt interfaces.
> ...
> 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, ...

Somebody already started this with XWindow2 ....

Well, as I see it, we have two choices:

1. Add some little more ugliness by introducing XView2.
   Hope that we'll find the time to do the "big cleanup". If so, XView2
   will be dead then, and have added a little more to the
   already-big-enough pile of legacy API.

2. Change XView now and here, not introducing new legacy API, not adding
   to API ugliness, not waiting for some future redeemer giving us all
   the resources to do the big cleanup.
   At the cost of introducing a (minor, as I tried to outline)
   incompatibility.

Well, yes, my wording was a little bit tendentious, but really, I prefer
2. over 1.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[Malte Timmermann]

Well, you attended the meeting about AWT improvements with Carsten many
month (or years?!) ago, where we discussed this.

Maybe you can dig out what our conclusion was that time, maybe with some
arguments? ;)

Then feel free to use that information and start a discussion thread
specific to AWT API improvements...

Malte.

Frank Schönheit - Sun Microsystems Germany wrote, On 06/30/09 15:09:

> Hi Malte,
>
>> I disagree with doing "selected" enhancements in single css.awt interfaces.
>> ...
>> 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, ...
>
> Somebody already started this with XWindow2 ....
>
> Well, as I see it, we have two choices:
>
> 1. Add some little more ugliness by introducing XView2.
>    Hope that we'll find the time to do the "big cleanup". If so, XView2
>    will be dead then, and have added a little more to the
>    already-big-enough pile of legacy API.
>
> 2. Change XView now and here, not introducing new legacy API, not adding
>    to API ugliness, not waiting for some future redeemer giving us all
>    the resources to do the big cleanup.
>    At the cost of introducing a (minor, as I tried to outline)
>    incompatibility.
>
> Well, yes, my wording was a little bit tendentious, but really, I prefer
> 2. over 1.
>
> Ciao
> Frank
>

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

[Juergen Schmidt-3]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Malte,
>
>> I disagree with doing "selected" enhancements in single css.awt interfaces.
>> ...
>> 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, ...
>
> Somebody already started this with XWindow2 ....

exactly and the questions is why not. It's better to do simply start and
do it step by step than waiting on the big shot. And the argument with
the oneway calls is obsolete anyway.

>
> Well, as I see it, we have two choices:
>
> 1. Add some little more ugliness by introducing XView2.
>    Hope that we'll find the time to do the "big cleanup". If so, XView2
>    will be dead then, and have added a little more to the
>    already-big-enough pile of legacy API.
>
> 2. Change XView now and here, not introducing new legacy API, not adding
>    to API ugliness, not waiting for some future redeemer giving us all
>    the resources to do the big cleanup.
>    At the cost of introducing a (minor, as I tried to outline)
>    incompatibility.
>
> Well, yes, my wording was a little bit tendentious, but really, I prefer
> 2. over 1.

me too. The "big cleanup" should maybe end in a completely new toolkit
(at least from my perspective). We learned a lot since the beginning and
probably a new toolkit would result in a cleaner, more intuitive and
better to use APIs. Talk with people who try to implement new controls...

But as long as we see no clear signal to do it or as long as we don't
see a real investigation in this direction we should try to improve the
stuff we already have step by step.

Juergen

>
> Ciao
> Frank
>


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

[frank.schoenheit]

Hi Malte,

> Well, you attended the meeting about AWT improvements with Carsten many
> month (or years?!) ago, where we discussed this.
>
> Maybe you can dig out what our conclusion was that time, maybe with some
> arguments? ;)
>
> Then feel free to use that information and start a discussion thread
> specific to AWT API improvements...

Hmm? I think I do not get you here.

I do not have any plans to start an "improve the AWT toolkit" project
here and now. That's just not my focus at the moment.

Are you seriously suggesting that we should not do the small and
innocent change, but aim for the make-everybody-happy solution instead?

Is there a good reason to not do the changes incrementally? And no, "we
once decided against getter methods since they are synchronously" is
*not* a good reason, sorry.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[Malte Timmermann]

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)

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 think it's better to break AWT API compatibility once, instead of many
times in many releases.

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.

Malte.

Frank Schönheit - Sun Microsystems Germany wrote, On 06/30/09 15:31:

> Hi Malte,
>
>> Well, you attended the meeting about AWT improvements with Carsten many
>> month (or years?!) ago, where we discussed this.
>>
>> Maybe you can dig out what our conclusion was that time, maybe with some
>> arguments? ;)
>>
>> Then feel free to use that information and start a discussion thread
>> specific to AWT API improvements...
>
> Hmm? I think I do not get you here.
>
> I do not have any plans to start an "improve the AWT toolkit" project
> here and now. That's just not my focus at the moment.
>
> Are you seriously suggesting that we should not do the small and
> innocent change, but aim for the make-everybody-happy solution instead?
>
> Is there a good reason to not do the changes incrementally? And no, "we
> once decided against getter methods since they are synchronously" is
> *not* a good reason, sorry.
>
> Ciao
> Frank
>

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

[Thorsten Behrens-3]

Hi Malte,

you wrote:
> I think it's better to break AWT API compatibility once, instead of many
> times in many releases.
>
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 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 [...]
>
This is totally misleading. It's highly unlikely that the change Frank
is proposing will cause any external incompatibility.

Cheers,

-- Thorsten

[frank.schoenheit]

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         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[Mathias Bauer]

Thorsten Behrens wrote:

> Hi Malte,
>
> you wrote:
>> I think it's better to break AWT API compatibility once, instead of many
>> times in many releases.
>>
> 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. The change
basically would be to replace every setSomething() call by an attribute
in that interface and to add the (in most cases) trivial implementation
everywhere. All in all a few days of work for an experienced developer.

In that case I would like to see some more from Carsten's suggestions
for awt changes becoming implemented (as much as we can add without
holding back the "add the get methods" task force).

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@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> Is there a good reason to not do the changes incrementally?
Yes, there is a very good reason. Every incompatible change causes pain,
 no matter how many individual changes it contains. So putting as much
changes together as possible into one change is better.

In case you don't see it: the biggest pain is caused by the fact that we
have to declare every extension as incompatible in every release where
at least one incompatible change has been made, as there is no way to
find out which types an extension uses (and it may be exactly the one
you have changed). So your plea for incremental incompatible changes
even in minor releases basically destroys the idea of extensions more or
less completely, as their life cycle effectively would be limited to a
maximum of six months. In fact it's even less than that as you would
gain 6 months only if the extension was released at the same time as the
office version it is compatible to.

I don't see a big problem with having an XView2. These are just names,
nothing more.
The code using XView2 wouldn't be better if it used XView instead. In
case your esthetical feelings were hurt by the "2" at the end, a simple
macro

#define XVIEW XView2

or similar would solve this at least for your code without hurting
others by an incompatible change.

There is no advantage in the incompatible change except that it could be
seen as a little bit less ugly (though I even don't see that). That's
not the kind of pain that I would see as a justification for an
incompatible change.

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@...

[Mathias Bauer]

Juergen Schmidt wrote:

>> The given XView interface is effectively *only* implemented in the
>> toolkit module, and chances that it's implemented outside the OOo code
>> base are rather low (since all the code around it does not really allow
>> for pure UNO components outside the OOo code, but that's another topic).
>> So, I'd say we're on the safe side here.
> i agree that we are probably safe here. But it shows also that a general
> rule is or can be problematic. Whereas a change like yours is probably
> harmless other changes of the same category can break many external
> solutions depending on the usage of the changed interface. That is the
> reason why we should discuss the changes in public and find a common
> agreement for the proposed changes...

It's my experience that establishing roles with too much preconditions
will cause endless discussions, not in every case, but in many.
So I would prefer to treat every incompatible change in the same way.
I could accept to make one exception: if an API is not implemented or
used in OOo at all we can safely assume that changing (or better:
replacing) it will not cause problems in extensions or code working with
OOo. But if an interface is implemented or used in OOo it's just wild
guessing whether it is used somewhere else and leaves too much room for
discussions.

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@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> 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*.

Sorry, where is the problem? Does a "2" in an interface name let your
code crash or create maintenance problems? Does it create bugs, make
your program slower?

I don't buy your argument that a "2" in an interface name makes our API
less compelling. It didn't prevent millions of developers from using COM
APIs on Windows and no serious developer will be held back by it in OOo.
 It would be embarrassing to have each and every interface in AWT
doubled for the "get" methods, and I can see value in the complete
overhaul, but I don't see an urgent need for changing this in a single
interface.

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@...

[frank.schoenheit]

Hi Mathias,

>> Is there a good reason to not do the changes incrementally?
> Yes, there is a very good reason. Every incompatible change causes pain,
>  no matter how many individual changes it contains.

Indeed.

Changing XView to contain that additional method creates pain now.

Creating an XView2 now and absorbing it in XView in OOo 4.0 creates pain
at a later time.

I'd say that the former pain is smaller than the latter, and thus I'd
like to implement the first solution, not the second.

So, it's not (only) about the pain an XView2 would cause now (which,
except in terms of highly subjective "ugliness", might not bee to high -
admitted), but also about the maintenance pain it will cause later. It
would add yet another item to the "if we ever touch this, then let's do
it all at once" pile - making it less likely for this pile to ever be
stripped.

> In case you don't see it: the biggest pain is caused by the fact that we
> have to declare every extension as incompatible in every release where
> at least one incompatible change has been made, as there is no way to
> find out which types an extension uses (and it may be exactly the one
> you have changed).

Sorry, but you should know better than this. We already talked about
which changes cause which type of annoyance to extensions, and adding a
method doesn't invalidate all existing Java extensions, nor Basic nor
Python nor JavaScript nor BeanShell extensions. All those will continue
to work. So your argument is pointless here, as changing an interface as
proposed does only invalidate C++ extensions, and even those only if
they use the interface in question.

> But if an interface is implemented or used in OOo it's just wild
> guessing whether it is used somewhere else and leaves too much room for
> discussions.

I think that developers working at OOo (API) code for for a decade and
more can do very educated guesses about this, and I wouldn't disqualify
an opinion backed up by that amount of experience as "wild guessing".

> It's my experience that establishing roles with too much preconditions
> will cause endless discussions, not in every case, but in many.
> So I would prefer to treat every incompatible change in the same way.
> I could accept to make one exception: if an API is not implemented

IIRC, 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.


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?

Ciao
Frank
--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[frank.schoenheit]

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.

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!

That's only the most prominent example which comes to my mind when we
talk about pain here. There could be much more.

No, "If the pain is big enough, then just fix it!" is pointless, as
there are more side constraints than actual pain. Long-term
sustainability is sacrificed to short-term profit, here and everywhere else.

It's always discuss-worthy whether the accumulated pain for a
non-optimal solution is worse than the short-term pain of a better
solution, but the "...then the pain is obviously not big enough." is
simply wrong, IMO. Not if we look out more than a few weeks or months.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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