[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-dev] Add @noextend and @noimplement tags to cdt.make.* and cdt.managedbuilder.* plugins
|
I created
bug 301373 to get that done. Please, let me know if you think any class/interface in public packages of these plugins should not receive the @noextend and @noimplement tags.
Thanks,
Andrew
On Wed, Jan 27, 2010 at 1:00 PM, Andrew Gvozdev
<angvoz.dev@xxxxxxxxx> wrote:
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
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