For AST it will be more difficult to make it not depend on DLTK (or we have to duplicate classes). Like Dawid said to Eenhuis:
"PDT have two AST models: 1. One based on DLTK basic elements (very similar to JDT Compiler model). It's used for validation, type inference and code assist. 2. Internal PDT DOM AST, it's more heavy, and available for current editor only (see SharedASTProvider). It's used for code manipulating, highlighting and formatting." But idea is great if we could package lexer/parser/ast source code in such way they only depend on JDK, JFlex, CUP and some generic libraries ;) From: micha...@zend.com To: pdt-dev@eclipse.org Date: Thu, 11 Aug 2016 19:48:48 +0000 Subject: [pdt-dev] remove project notion from all php lexers +1 from me for removing IProject from lexer related elements and one highlighter for all versions I think removing IProject from code is very good idea. In general it would be nice to decouple lexer/parser code from Eclipse api as much as possible. I can imagine that lexer/parser/ast source code would be interesting as separate bundles without Eclipse/DLTK/WST dependencies. At the moment I cannot imagine any problem with only one highlighter. Parser will do the validation and that should be enough from user point. Michal Od: pdt-dev-boun...@eclipse.org <pdt-dev-boun...@eclipse.org> w imieniu użytkownika thierry blind <thierrybl...@msn.com> Wysłane: 11 sierpnia 2016 16:44 Do: pdt-dev@eclipse.org Temat: [pdt-dev] remove project notion from all php lexers Hi team, I have a technical question :) While I worked on bug 498877, I saw that the lexers need project informations for various operations (like to retrieve task tags defined for a specific project or to retrieve the PHP version of a project to decide which highlighter version to use, ...). Sadly there are cases where lexers are created on-the-fly by eclipse to do some specific operations (document reparsing, reconciling or workspace builds are done on temporary&buffered documents for example) that are "detached" from any project notion. Technically speaking, in those cases we work with project properties set to null ;) So I would like to remove in the future all traces of "project" properties inside of php tokenizer, highlighters, PhpScriptRegion, PhpTokenContainer,... as it is not the way to go (looking how eclipse works). A good example is the hacky way used to set the project for document lexers in the PHPStructuredEditor class : PhpSourceParser.editFile.set(resource); Clearly that's a hack to find a way to provide a project value to lexers created on-the-fly by eclipse ;) For now in the PDT lexers, project informations seem only necessary to : - see if a project supports ASP tags (is this still used?) - retrieve task tags defined per project (patch for bug 498877 will remove that) - choose the highlighter version depending on project settings So my question is: why do we actually need a highlighter per php version? Why just not use the highlighter for the most recent supported php version (7.1)? Is there any reason to not highlight most recently added php keywords on older php versions (even if not "supported")? It would simplify a lot of code just to use one highlighter + php tokenizer + phpdoc scanner everywhere ;) Thierry. _______________________________________________ pdt-dev mailing list pdt-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/pdt-dev
_______________________________________________ pdt-dev mailing list pdt-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/pdt-dev
