[eclipse-dev] Re: [cross-project-issues-dev] API tooling now supports th

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

The contract between a superclass and its subclasses is defined by the 
superclass (separate from interface tags). Currently, the only tags we 
support on methods are @noreference (private) and @nooverride (final). We 
do not currently have a tag that enforces a call to super methods.

Darin 




Randy Hudson <hudsonr@xxxxxxxxxx> 
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
11/24/2008 10:39 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
eclipse-dev@xxxxxxxxxxx
Subject
Re: [cross-project-issues-dev] API tooling now supports the @noextend 
restriction on interfaces






If the subclass doesn't call super, is there a way to make that generate a
warning or error (unless suppressed)?

--Randy



 
             Darin Wright 
             <Darin_Wright@ca. 
             ibm.com>                                                   To 

             Sent by:                  cross-project-issues-dev@xxxxxxxxxx 

             cross-project-iss         g, eclipse-dev@xxxxxxxxxxx 
             ues-dev-bounces@e                                          cc 

             clipse.org 
                                                                   Subject 

                                       [cross-project-issues-dev] API 
             11/21/2008 03:55          tooling now supports the @noextend 
             PM                        restriction on interfaces 
 
 
             Please respond to 
               Cross project 
                  issues 
             <cross-project-is 
             sues-dev@eclipse. 
                   org> 
 
 




API tooling now supports the @noextend restriction on interfaces.
Components with API interfaces should read/follow instructions below.

** What is affected: **

API interfaces defined with the @noimplement restriction.

** Description:  **

In release 3.4 (Ganymede) and earlier, API tooling supported one
restriction for API interfaces - @noimplement. This restriction indicated
an interface was not to be implemented *or* extended by clients. To allow
for more flexibility, Eclipse 3.5 (Galileo) separates these concerns with
two restrictions - @noimplement and @noextend. This allows an interface to
be extended when it is not intended to be implemented directly. For
example, in some cases clients are not allowed to implement an interface
directly, but can subclass an existing implementation and extend the base
interface/class with extra function (@see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=230189 for a discussion and
examples).

** Action required:  **

Component owners need to decide where to add @noextend tags on existing
interfaces.

To have exactly the same API contract as specified in 3.4, @noextend tags
can be added to all interfaces specified as @noimplement. However, this
can be decided on a case by case basis. Generally, the @noextend can be
omitted, as clients that extend and implement a @noimplement interface
will still be flagged with errors. However, if you would like to reserve
the right to add constants (public static final fields) to an API
interface in the future, you must add the @noextend tag. This is because
adding a field to an interface is binary incompatible if clients can
extend or implement an interface (@see
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces
).
Adding an API restriction to a class/interface is usually an error -
however, API tooling allows you to add @noextend tags without penalty in
release 3.5, since this specifies the same contract as in 3.4. If you were
to wait until a later release to add the additional tag, and error would
be generated.


Darin Wright
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev