Hi Marek,
At this moment both are required and it probably will not change for a long time
DOM AST is a more complete and can be modified in runtime, unlike to compiler AST.
I suggest you use a DOM AST together with ASTRewriter (very nice class ported from JDT). ASTRewriter use formatter internally and your SourceModules will be always formatted properly (in theory).
I thought about it for class/interface and getter/setter generator for PDT-Eg Core Plugin.
How to use ASTRewrite you can check here: https://github.com/pdt-eg/Core-Plugin/blob/master/org.pdtextensions.core.ui/src/org/pdtextensions/core/ui/contentassist/AssignToLocalCompletionProposal.java
-- Dawid Pakuła +48 795 996 064 On 15.11.2013 23:26, Dawid Pakuła wrote: > One of JDT AST models contains also logic for FlowAnalysis. > > At first look PDT ASTs works like in JDT, but… Older (JDT like) AST contains binding resolver, which using compiler AST and > sometimes whole DLTK TI framework. > Older AST (JDT like) is mostly used directly in UI with many utils, functions and widget ported from JDT (many of them still > contains java/jdt keyword in comments and strings). And as I see, it is always created while using editor. He has ability to > record his changes. > Second AST (compiler subnamespace) its created for DLTK integration, but it also used in outline, syntax coloring etc… This > AST is cashed by DLTK > > In summary, it looks like an unfinished migration to DLTK. I do not see the terms of use of these models. > > Maybe will be possible to transform from one to another (by special visitor), instead of duplicating parsers. > > Dawid >
Anyone can tell me, which AST should be use and will be developed in future? I would like to refactor class/interface wizard (creating code based on AST models).
M.M _______________________________________________ pdt-dev mailing list pdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/pdt-dev
|