Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pdt-dev] Handly based model

I know only about closed source: https://wiki.eclipse.org/Handly/Adopters  In handly repository you can find 3 examples:
  1. Simple based on xtext
  2. Based on Language Servers
  3. Forked JDT transformed to handly

Handly is „only” model. Other stuff could be reused from DLTK. Main reason is to used model where possible, rather than traverse AST each time (traits, use statements, phpdoc type)

--
Dawid Pakuła - w3des.net
On 20 Jan 2020, 10:05 +0100, thierry blind <thierryblind@xxxxxxx>, wrote:
Hi Dawid,
Handly seems very interesting, is there some big open source project using it?
I would like to have a look at some code to have a better idea of its possibilities.

Thierry.


De : pdt-dev-bounces@xxxxxxxxxxx <pdt-dev-bounces@xxxxxxxxxxx> de la part de Dawid Pakuła <zulus@xxxxxxxxx>
Envoyé : lundi 13 janvier 2020 17:49
À : PDT Developers <pdt-dev@xxxxxxxxxxx>
Objet : [pdt-dev] Handly based model
 
Hi,

Since couple months I’m playing with handly[1], and I have to say it’s look very, very interesting.

It will allow us to take full control of our model, and rather loosing time for adapters, managers and synchronizers.

In current state DLTK models is mostly copy/paste/modify model from JDT, and have a lot of limitations:

1. Strong separation between class path and other resources:
 1. Hard to play with files that have mixed content
 2. Nearly impossible to add only one file to buildpath
2. No interface list in ITypes
3. No real support for nested namespace
4. No support for multiple ImportContainer
5. No ability to keep PHPDoc reference or other information for IType/IFile/IMethod
6. Impossible to keep in regular way information about trait structure
7. No ability to register class aliases
And more…

PHP evolve year by year, new construct might require even more model elements, maybe even true annotations }:->

DLTK model is very complex. It not only contain model structure, but also shortcuts for partial TI/CA, TypeHierarchy calculations… Many of this features doesn’t work on PDT or works incorrectly.

For now, I would like to ask, how our model should look like. 

Do we need strong separation between project and IProjectFragments? Or should it should be more like composer.json.



_______________________________________________
pdt-dev mailing list
pdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/pdt-dev

Back to the top