Javac Tree API suggestions to more closely model source code

[Jonathan Gibbons]

Internally, the javac tokeniser does distinguish comments, although 
non-javadoc comments are dropped.

The hard thing with comments and ASTs is figuring out where to put them. 
Even javadoc comments can be problematic.  Probably the best that could 
bbe done is some sort of table on the side.

-- Jon

On 09/30/2014 09:44 AM, Martin Buchholz wrote:
> Just a few meta-comments:
>
> As popularized by the Go folk, programming language styles are moving 
> in the direction of automatic reformatting, especially of whitespace, 
>   If done well, it's very valuable, freeing the programmer from having 
> to worry about the formatting.  But it's very hard for the program to 
> do as well as a careful programmer doing source code layout, 
> reminiscent of the ancient debate of assembly language programmers vs. 
> "high-level" languages like C.
>
> The hardest thing to get right is comments (this is the experience of 
> the Go folk).  Comments often refer to some other part of the AST. 
>  javadoc comments refer to the subsequent program element, end-of-line 
> comments typically refer to the preceding code on the same line (which 
> may not correspond to a single AST node), and other comments may refer 
> to a "section" of subsequent program elements, e.g.
>
> // --------------- Constructors ------
>
> One consequence of moving to automated formatting may be a need to 
> introduce new comment types, as with the distinction between /* and 
> /** to communicate intent to the formatter.
>
> Although Harry is currently focused on whitespace only, a natural 
> direction is to unconditionally reorder any modifiers encountered into 
> canonical order, as mandated by some existing java coding styles.