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 <thierrybl...@msn.com>, 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-boun...@eclipse.org <pdt-dev-boun...@eclipse.org> de la part de > Dawid Pakuła <zu...@w3des.net> > Envoyé : lundi 13 janvier 2020 17:49 > À : PDT Developers <pdt-dev@eclipse.org> > 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. > > [1] - https://projects.eclipse.org/projects/technology.handly > > > _______________________________________________ > pdt-dev mailing list > pdt-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.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://www.eclipse.org/mailman/listinfo/pdt-dev
