Hi,

good to know. Current PEX framework is written (broken :P) mostly by me and 
based on this experience I’m designing new version which I planned to propose 
as PDT plugin. Probably for Mars.2 (performance is critical part for me).

Separate to “require / not require” index isn’t enough, because still will be 
slow. Even with index. Index usage might be also easy reduced by class loaders 
(see bug 472758 [1] }:->).

A lot of problem could be collected during standard Type Inference (JDT calls 
this flow analysis) : class / variable / method not exists or even deprecated 
calls . DLTK don’t allow collecting IGoal results during inference process 
right now. I plan to propose patch, because I need it to improve syntax 
highlighters performance, especially deprecation highlighter.
Others need access to type information (implementation  / override etc…) so as 
you said index (or class loaders helpers).
Others need only content / ast
Others, mostly framework specific, might need three of above or nothing (own 
index/builders etc…).
Also validator chain should be introduced. If any validator produce problem, 
validator participant should be able to mute / extend (ideal use case could be  
usage validator where doctrine extension could).

but if we talking only about ui (user point), would be nice to have not only 
categories and validator names with severities, but also ability to introduce 
some options to validator (for example be case sensitive) like in JDT.

[1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=472758

-- 
Dawid Pakuła
+48 795 996 064

On 13 Aug 2015 at 23:47:09, Michał Niewrzał ([email protected]) wrote:

Hi All,

I want to start discussion around semantic analysis in PDT. This topic is 
covered in PDT Extensions and also in Zend Studio. Now we have first SA rule in 
PDT[1]. I think it is time to provide base for SA in PDT. One point where all 
extensions can add own validators in ordered way. 

From technical point of view I don't have full vision how it should look. I 
think main change is to choose best approach how/when validate source code. For 
many checks full indexing is necessary for other only AST tree. To start with 
something I will write few ideas:
* one common preference page, categories similar to JDT
* maybe each extension can add own tab to this page to avoid confusion with 
doubled validators
* provide two types of validators:
   * basic - no indexing data needed, can be triggered by IBuildParticipant
   * advanced - indexing data necessary, triggered after indexing
* users can on/off both types separately
* maybe we can think about validation only on demand or on file open to avoid 
extending build/indexing time

As I wrote it's only general description what is in my head but it will be 
easier to comment :)

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=354782

Michal
_______________________________________________  
pdt-dev mailing list  
[email protected]  
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit  
https://dev.eclipse.org/mailman/listinfo/pdt-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
pdt-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/pdt-dev

Reply via email to