Idea - Expose some kind of service?

[ghost]

Hello

To take the package one step further, maybe it would be a good idea to expose a service that allows other packages to access information we're already reading (such as proxy.methods, a getCurrentMethod method, ...). The base we're developing here has so much potential beyond our current scope:

• We could lint class names that we don't recognize (we're already scanning for class names in comments anyway).
• We could lint members that aren't recognized or are incorrectly accessed (e.g. private methods from an outside scope).
• We could lint docblocks if the type hint isn't the same as the docblock (or parameters are missing).
• We could automatically generate getters and setters for known properties of classes.
• We could automatically create missing properties the caret is on when pressing a shortcut such as alt-enter.
• We could automatically create missing interface methods or abstract methods that need to be implemented the caret is on.
• ...

I would like to do all of these things myself but just as you (and probably everyone) I don't have an infinite supply of time and I'd rather spend it focusing on bugfixes and improvements on the current code right now. Maybe exposing a service that allows access to our information will encourage other developers to start developing these features and keep the scope of this package contained? Ideally Atom could even be turned into a full PHP IDE by installing this package along with other packages that do the things listed above!

Thanks in advance

[Peekmo]

Hello,

Interesting in fact, but I prefer joining all efforts in a same package (so having contributions to improve this one), in order to avoid installing 100 packages.

But, I would like to provide some events to enable framework's plugins. Because framework specific support should not be part of this plugin in my opinion. But perhaps it should. I don't know..

[ghost]

Even though it allows you to easily disable parts (and compilation) of code you don't require, I must say I agree with finding it more convenient to have one central package.

I guess the problem we currently have, is that the name of the package is not really correct anymore; we're already doing a lot more than just autocompletion (tooltips, code navigation, annotations, ...). The question then becomes: "If the current name isn't good anymore, what would be a good name?".

What we're doing right now is already evolving towards basic IDE-like functionality. However, people have widely varying thoughts on what an IDE should and shouldn't do. For example, a lot of people might also start expecting debugger integration. This is something we could also do. I guess all of this depends a bit on how far (or not) you want to take this package?

[ghost]

I just wanted to let you know that I'm doing some experimenting with this so you have a better idea what I'm thinking of ([1] and [2]). Regarding the problem of having too many small packages, would it perhaps be a solution to have some kind of convenience 'bundle' package that uses e.g. Git submodules to fetch all the repositories and then directly activates all the subpackages by itself?

[1] https://github.com/Gert-dev/php-integrator-base [2] https://github.com/Gert-dev/php-integrator-tooltips

[Peekmo]

I don't like it.

I don't want to take time to maintain some modules completely decoupled. I want to keep the possibility to add an ugly fix in some files if there's a big bug with just side effects on this plugin and not on an other one.

Perhaps the plugin should be renamed in fact, because it gives more than autocomplete today.

Note : If this plugin were not rely on composer to work, decoupling things would be interesting, but here it's too specific to composer.

[Peekmo]

Hello,

As I see, you're now working on your side. Should I remove you from repository collaborator or will you contribute there again ?

Thank you for your answer, Peekmo

[ghost]

Hello

You are correct, but it was never my intention to create a competing fork. What you say here is certainly valid and I respect your opinion, so I didn't want to disturb you further with this. However, I feel I must try this out to see if it will benefit the community (in the sense that it might stimulate the creation of more PHP-related packages).

What I wanted to do is create several packages that each use the service from the base package (which handles indexing and exposes convenient functionality) and handle their own tasks: tooltips, autocompletion, annotations, etc. In theory it would also be possible to make this package a 'consumer' of the service that I'm now exposing in the 'base' package (which is essentially just the PHP side, proxy, parser, config, etc.). However, you already stated that you'd rather avoid this, which of course is a valid choice. On the other hand this leaves me with the choice to either drop my idea completely or do it anyway, but at the cost of our collaboration. I can't really say I'm happy with either of these choices as I enjoy working on this package with you.

If you wish, you may remove me as collaborator. If I find any serious bugs, I'll continue to report them here so you can also benefit from this.

[Peekmo]

Hi,

No problem, so I remove you as you're not happy from these choices and you'll (of course) not working on it anymore.

Regards