Re: [eclipse-dev] New API tooling tags

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I like having a human-readable text
description next to the tag.  This may seem redundant if you understand
the meaning of these tags, but these are not standard javadoc tags and
we can't assume users browsing the source will understand exactly what
they mean.

Markus Keller <markus_keller@xxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/03/2008 09:12 AM

Please respond to
"General development mailing list of the Eclipse project."        <eclipse-dev@xxxxxxxxxxx>

To	"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-dev] New API tooling tags

Redundancy in code is evil.

I would only keep the old comments if they add more information than the
API tools tags can express.
Otherwise, add the API tools tag(s), but *without* additional description.

If we fear that the API tools tags are not self-explanatory, we could add
some tooling
support (e.g. to expand them into the full blurb for Javadoc export and
in 
hovers).

Markus




Martin Aeschlimann/Zurich/IBM@IBMCH 
Sent by: eclipse-dev-bounces@xxxxxxxxxxx
2008-04-03 14:53
Please respond to
"General development mailing list of the Eclipse project." 
<eclipse-dev@xxxxxxxxxxx>


To
eclipse-dev@xxxxxxxxxxx
cc

Subject
Re: [eclipse-dev] New API tooling tags






We would rather keep the old comments. First it's a lot of work to do it.
Second, most comment contain extra information which sometimes can't be
expressed by the new tags.

 * <p>
 * Note: this: class is not intended to be extended outside of the
refactoring framework.
 * </p>

 * <p>>
 * This class should be subclassed by clients wishing to provide a special
move
 * processor.
 * </p>

Thoughts?.

Martin




  
  From:       Olivier Thomann <Olivier_Thomann@xxxxxxxxxx>
    
  
  To:         "General development mailing
list of the Eclipse project." 
<eclipse-dev@xxxxxxxxxxx> 
  
  Date:       03.04.2008 14:36   
  
  Subject:    Re: [eclipse-dev] New API tooling tags  
 
  





API Tools doesn't remove the existing description in the javadoc.
It only adds a @noimplement followed by the description based on the
component.xml contents and this should replace the old one. So the user
should remove the old one and keep only the new javadoc tags.
Since the wording of the old description is not consistent among bundles,
we could not simply remove the old one.

API Tools also doesn't add @noinstantiate for abstract classes and doesn't
add @noextend for final classes.

Hope this clarify what API Tools is doing.

Olivier




Szymon Brandys <Szymon.Brandys@xxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx
2008-04-03 06:33
Please respond to
"General development mailing list of the Eclipse project."
<eclipse-dev@xxxxxxxxxxx>


To
"General development mailing list of the Eclipse project."
<eclipse-dev@xxxxxxxxxxx>
cc

Subject
[eclipse-dev] New API tooling tags






I noticed that some redundant entries are created in javadocs,
when a project is converted to use API tooling.

For instance for an interface that is not intended to be implemented, I
will have the old entry "This interface is not intended to be implemented
by clients."
amd the new "@noimplement This interface is not intended to be implemented
by clients.".

I would move the comment to the tag. But maybe there are some tools that
can ignore new tags and users would not see it.
Of course we could just add a tag with no comment and leave the old entry
in javadoc.

Any thoughts?
--
Szymon Brandys

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev


_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev


_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev


_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev