Community
Participate
Working Groups
To make the language stubs 1. more reusable and 2. make it easier to contribute without checking out the complete PDT source, it would be good to move the language stubs from plugins/org.eclipse.pdt.core/Resources/language to a separate repository, and make it available on github.
I'm not quite sure how we can make this. Anything we want to distribute with PDT has to be in Eclipse git repo, has to pass the IP process. There's room for a plugin that would e.g. consume API stubs from somewhere on internet...
I'll try to push our current contributions faster
for the record, Robert pointed me at very cool project for generating PHP stubs: https://github.com/schmittjoh/php-stubs
From the Eclipse Process point of view we can do the following: 1. Move the stubs and the complementary tools (like generators) to a separate subproject under PDT, e.g. "Eclipse PHP Stubs" project. 2. Request the git repo for this new project to be hosted on GitHub [1]. 3. Request to distribute the stubs under the Eclipse Distribution License [2], which is based on the New BSD License and is more permissive than EPL. All this would make it easier to reuse the stubs outside of Eclipse and would bring more contributions. [1] https://wiki.eclipse.org/Social_Coding/Hosting_a_Project_at_GitHub [2] https://www.eclipse.org/org/documents/edl-v10.php
+1 from me On this project we could divide stubs to PHP version related and universal (mostly on pecl, for ex xdebug).
I think it would be nice to refresh this topic :) How we should start? By creating sub-project for PDT?
I don't think sub-project is necessary for now. Separate plugin with stub utilities should be enough ;)
(In reply to Dawid Pakula from comment #7) > I don't think sub-project is necessary for now. Separate plugin with stub > utilities should be enough ;) What do you mean separate plugin?
current stub-utility is simple php script, hard to maintain. Keeping it outside "java" project should simplify life.
After short discussion with Kaloyan we concluded that it would be interesting to check another option instead of creating yet another php stubs project. PHPStorm has nice stubs [1] for CA and the license is Apache 2. It should be possible to use them with PDT. Stubs are already used by php-language-server. [1] https://github.com/JetBrains/phpstorm-stubs WDYT?
New Gerrit change created: https://git.eclipse.org/r/100200
I like these stubs but: 1. Today we have stubs per php version. If we switch to "always-complete" stub version, we will need @since tag validator in near future. 2. CQ will be required after each update. 3. These stubs haven't constants like false / true / null .. so bug 480451 will be important. 4. We have to be sure that stubs are parsed always via latest parser.
(In reply to Dawid Pakula from comment #12) > I like these stubs but: > 1. Today we have stubs per php version. If we switch to "always-complete" > stub version, we will need @since tag validator in near future. If we decide to go in this direction it will take time before switch will be done and we won't switch until all parts will be ready. > 2. CQ will be required after each update. I think this will be most problematic because stubs have no versions and we will need to decide when update stubs (and create new CQ). > 3. These stubs haven't constants like false / true / null .. so bug 480451 > will be important. Like 1. > 4. We have to be sure that stubs are parsed always via latest parser. Like 1.
Now when I'm looking at @since validator I see that this can be a little bit problematic. Currently we don't have a place to store info about PHP version from @since tag and I think parsing this on demant won't be a good option. We can create modifier for every PHP version but I also not sure if it's a good idea. A similar problem is with @deprecated tag. PDT needs to know about the version from tag to highlight (or not) code according to project's PHP version.
So I'll start from DLTK. We need ability to store additional information's for each IMember (maybe event IModelElement), this will allow to stop scanning AST each time when we need some additional informations from PHPDoc. I thinking about IMember#properties to store key=value elements.
(In reply to Dawid Pakula from comment #15) > I thinking about IMember#properties to store key=value elements. Sounds good. At least it will be flexible enough to use it with other features.
