Dawid,
This is a lot to take in and as someone not very familiar with the inner workings of Eclipse as it relates to PDT (or much else), so I am not sure how valuable my input could be in light of that. Nonetheless, I'll reply inline below (sorry for top-posting!).
On Fri, May 8, 2020 at 3:59 pm, Dawid Pakuła <zulus@xxxxxxxxx> wrote:
Hi,
Despite to GitHub move I have couple plan for future releases.
Since couple releases, thanks to hard teamwork, PDT is finally fast enough to consume a lot of large projects in one single workspace.
But in meantime we started to spinning around, new features often require lot’s of workaround, bypass DLTK/WTP, etc..
It’s not direct problem of DLTK, but PHP evolve a lot since 5.4 and they haven’t plan to stop (PHP 8.0 will have attributes!!! :P).
So, I think it’s time to start dropping DLTK as language support skeleton.
How can someone who is not familiar with DLTK understand what DLTK brings to the table and what the ramifications of this would be? How much would you have to implement yourself to cover the gaps left by leaving DLTK? A list of pros- and cons- may be helpful to understand this if it's not too arduous.
I would like to have 2 kind of PHP projects:
1. Strict structure, fully controlled by composer (or anything else) and it’s configuration, where PDT will be able to correctly validate files, or react for file move
2. Weak structure, where everything is indexed, class path validation even if exists, it can be only on selected folders.
Is it fair to say 1 is akin to PSR-based rules, while 2 is older-style, legacy PHP applications where you have to implicitly follow PHP's logic to know what is included where, etc.? If so, that kind of makes sense, but how is this better (from a user's perspective) than something that "just works" like what we have now, for the most part?
Aside from some of Laravel's Facades, most of my projects seem to be more-or-less understood well by PDT and I can hope between references and definitions and get the code suggestions I'm looking for. I wonder if I'm missing the point of what you're saying here...
In both cases we need much simpler model without garbage from Java models container, class folders, external containers etc..
This sounds good.
Also completely independed to indexing and searching.
I don't understand if this is good or bad. Doesn't some searching work across classes, functions, and so on?
PHP model should be based on handly with ability to register alias, traits and others. This later allow us to simplify project import/creation, and later maybe ability to prepare PDT-LS for VSCode fans ;)
What is
PDT-LS?
Without this we will fall, even on GitHub :P
Off course some DLTK elements will be still valuable like Type Inference, Low-level indexing etc…
During this process I plan to re-implement Twig/Doctrine/Symfony support (this projects are maintained by me only) and add to PDT Core as example how PDT should/could be extended.
If we find volunteer, maybe other popular projects will add out-of-box support to PDT.
I think this all sounds great. Greater framework support would be very welcome. I'd love to have Laravel Blade template support as well as better understanding of Facades.
Maybe later we will try to untick from WTP (CSS/HTML code assist in php file) but for me is not priority now.
Can you clarify a little more on this?
Any thoughts?
I'm happy to be part of the discussion and hope I can help more in the future.
