« Return to Thread: adding a method to a published interface
Re: Re: [interface-discuss] adding a method to a published interface
by Juergen Schmidt-3
::
Rate this Message:
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@...
> 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.
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@...
« Return to Thread: adding a method to a published interface
| Free embeddable forum powered by Nabble | Forum Help |
