Community
Participate
Working Groups
It may be self-explanatory, but it's still needed.
Remy, there are unfortunately quite a number of internal classes that lack -any- jdoc... Not saying it's right, just pointing out that bringing the internal jdocs up to the same level as our public API is going to be a significant task...perhaps we should widen the scope of this defect?
(In reply to comment #1) > Remy, there are unfortunately quite a number of internal classes that lack > -any- jdoc... Eric, WorkbenchPart is a public class (http://help.eclipse.org/stable/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/part/WorkbenchPart.html) and the method in question is a protected method (http://help.eclipse.org/stable/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ui/part/WorkbenchPart.html#firePartPropertyChanged(java.lang.String,%20java.lang.String,%20java.lang.String)), was the "internal" comment a typo? > Not saying it's right, just pointing out that bringing the internal jdocs up to > the same level as our public API is going to be a significant task...perhaps we > should widen the scope of this defect? Potentially, we could try to do some sort of clean-up for all public types and their public/protected fields and methods. By clean-up I mean note them (since it may or may not take a while to actually write all them javadoc comments). Perhaps we can use JDT API to help us analyze this. Or maybe API tools? Then again, there are tons of warnings caused by ECJ that flags this, but I suppose it'd be better to have a list then click on them one by one?
Remy, my apologies. While the class is public the method in question is a protected method in a class that's declared as 'not to be subclassed by clients' (making it, effectively, internal). This (i.e. cleaning up the jdocs) would make a marvelous 'grass roots' task; it's non-complex in the sense that it doesn't involve getting into the code internals and has simply languished due to lack of resources...what do you think?
(In reply to comment #3) > Remy, my apologies. While the class is public the method in question is a > protected method in a class that's declared as 'not to be subclassed by > clients' (making it, effectively, internal). But adopters are supposed to extend ViewPart and EditorPart, which extends WorkbenchPart, so those protected methods are exposed to people that are implementing views and editors either way, no?
You are indeed correct...I admit that I would have declared the method 'final' since I can't envision anybody over-riding it but the way it's currently defined such a thing is possible. Are there other candidates that you've noticed as well? I'll take this and clean it up...just add candidates if you find them...thanks.
Moving to triage...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
