[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse-dev] New API tooling tags
|
The idea of the description behind the tags is that we can get a
consistent look for restrictions inside the javadoc.
Right now the comments are more or less anywhere in the javadoc. Most of
the time at the end, but this is not always true. So we end up with an
inconsistent documentation for the user.
Now if you see a better way to get the same result, I am listening.
Olivier
Markus Keller <markus_keller@xxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx
2008-04-03 09:12
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