Re: [cdt-dev] API changes in IOption (cdt.managedbuilder.core)

[Andrew Gvozdev <angvoz.dev@xxxxxxxxx>]

Hi Tony,

On Wed, Jan 27, 2010 at 3:13 AM, Leherbauer, Anton (Toni) <Anton.Leherbauer@xxxxxxxxxxxxx> wrote:

Hi Andrew,

 

I had a quick look at the patch and I don't think that this requires a breaking change.

The additional attribute is optional, so you can define a new extension interface which all

internal implementations of IOption (Option, OptionReference) implement.

 

On the other hand, IOption looks like it is not meant to be implemented by clients,

therefore it should have the "@noimplement" tag which allows you to add methods

without breaking the API. Adding the "@noimplement" is a breaking change in itself, though.

Yes, I think you are right on that.

  

In other words, if you are going to increment the major version number, I'd recommend

to tag public interfaces which are not meant to be implemented by clients with "@noimplement"

and thus avoid breaking changes later on.

 

There was bug 260830 to add @noextend and @noimplement tags to cdt.core and cdt.core.ui plugins a while ago. It was not done for any of cdt.make.* or cdt.managedbuilder.* plugins. I suppose it is the right thing to undertake for those too. It may be a good occasion to do it for 7.0. The problem of course is that it is not clear which classes are intended to be extended/implemented and which are not. One way is to add the tags for all classes where JavaDoc does not specify that explicitly en masse and ease restrictions after somebody complains/justifies that. Or is there a better approach?

Thanks,

Andrew

 

 

Cheers,

Toni

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: Tuesday, January 26, 2010 6:01 PM
To: CDT General developers list.
Subject: [cdt-dev] API changes in IOption (cdt.managedbuilder.core)

Hi,

There a new contribution bug 300707 to Build Settings UI to allow an integrator to specify a file-extension filter for FileListControl when browseType 'file' is used for an option (one example is C++ Linker->Misc->Other objects).

The request makes sense, however it breaks API adding new methods to IOption interface. Since we decided in favor of CDT 7.0 it is legitimate. However it is a core interface for MBS and I suppose some existing integrations may be broken. Is there any reservations against making these breaking changes in IOption for CDT 7.0?

Andrew

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev