Bug 29176 - [DOM/AST] Statement.get/setLeadingComment should be deleted
Summary: [DOM/AST] Statement.get/setLeadingComment should be deleted
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 2.1 M5   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords: api, readme
Depends on:
Blocks:
 
Reported: 2003-01-08 16:47 EST by Jim des Rivieres CLA
Modified: 2003-02-26 17:33 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jim des Rivieres CLA 2003-01-08 16:47:03 EST
Statement.get/setLeadingComment does not work properly in 2.0. After 
consideration, this is not a good approach to dealing with the general issue 
of comments and significant whitespace. For instance: 
- can't handle multiple end-of-line comments that precede a statement
- doesn't address analogous issue of trailing statement comments
It's not clear what the best approach would be, but this ain't it.
Consequently, it should be deleted (deprecated). We can add a better solution
later.

This is a breaking API change. However, AST.parseCompilationUnit never did set
the leading comment for any AST nodes it creates, the change is moot for those 
client. Clients that use these methods to remember a comment with a node they 
create can achieve the same thing with ASTNode.get/setProperty, so there is no 
loss of functionality.

See bug 28268 for a further discussion of the issue.
Comment 1 Jim des Rivieres CLA 2003-01-08 17:19:10 EST
Entered bug 29178 for improved mechanism.
Comment 2 Jim des Rivieres CLA 2003-01-10 11:29:55 EST
Added deprecation notices to Statement.get/setLeadingComment.
No changes are required to the implementation.
Comment 3 Olivier Thomann CLA 2003-01-13 08:39:52 EST
Both methods are deprecated.
Fixed and released in 2.1 stream. Why don't we simply remove them? To prevent 
compile errors?
Comment 4 Jim des Rivieres CLA 2003-01-13 10:45:52 EST
Actually removing the methods would break binary compatibility (it would cause 
linkage errors in existing 2.0 plug-ins that reference these methods).
Comment 5 David Audel CLA 2003-02-10 06:43:34 EST
Verified.
Comment 6 Jim des Rivieres CLA 2003-02-26 17:33:52 EST
Added API compatibility note to 2.1 release notes.