Community
Participate
Working Groups
2.1 When working with modifiers on method or field declarations, the AST gives not much help with the simple getModifier: int. Informations I am missing (and have to regain with the scanner): - order of the modifiers - positions of the modifiers Would it make sense to have a Modifier Node?
I would say that this should be done using the scanner. Jim, any comment?
I agree with Olivier that this kind of fine-grained lexical analysis should be done with the scanner. The approach taken from the outset was to keep the AST simple by eliminating a lot of the lexical details of the program text. The exact order and source positions of modifiers is one such example; the position of comments is another. All nodes carry accurate source positions, making it possible to tightly bound the range of source positions in which the tokens will be found. This support should be sufficient. I recommend closing this DCR.
Its my experience from working several weeks on the AST rewriting that the limitations you mention are acceptable: it's easy to set up a scanner to get positions of things like commas or semicolons. The only nasty nodes are the ones with modifiers and the arraycreation - there are many different modifiers -> big case statement again (maybe the scanner tokens could be categorized?) -> I must build up a structure - arraycreation is very complex due to the empty brakets which are only known by their number. For both nodes its for example hard to get the end position of all modifiers or brackets.
If we want to keep the DOM/AST API simple, we cannot add this new node. You can always on your side create a structure that wraps the modifiers or the array creation. Ok to close?
This won't be done as part of the DOM/AST API. It can easily be done using the scanner and the positions of the ASTNodes.
