Rubberduck: Sunsetting Rubberduck.API?

[retailcoder]

The COM API was originally intended to expose RD's internal awesomeness to VBA code, so as to enable some kind of reflection capabilities in VBA.

Problem is, it's a fringe feature that was never advertised, never really completed, and using it tends to make the VBE unstable.

Shall we cure it or kill it?

[bclothier]

IMPOV, the main problem with the API is that it's not very useful because in the end all it does is give you a giant list of all declarations from a parser that knows nothing about the add-in's parser's cache (meaning you must parse separately using API's parser to get the same information) and you don't have an easy way of filtering/searching the results.

So at very least, it needs a DeclarationFinder. There are probably other features that could be added but as it is right now, it is incomplete because of the lack of search/filter for the declarations.

However, as noted, it needs a maintainer, and we've been busy with other tasks. If there's no maintainer, I'm in favor for sunsetting it until someone comes along and takes it up.

[mansellan]

Sounds like it's in a similar spot to Source Control, except less used.

I vote we remove it for now, it can always be resurrected if need be.

[retailcoder]

The defunct Source Control panel is a good analogy, although lots of folks would use RD just for that, whereas the parser API... meh.

Let's kill it then.

[Greedquest]

Oh shoot, I'm developing something with it right now.

On a more constructive/ discursive note, IIRC one of the major reasons the Source Control feature was removed (as opposed to just no-longer maintaining) was that there are countless other (better) git & source control options available.

Rubberduck is however the only good VBA parser I know of, and exposing those parsing tokens seems better than not.

[rubberduck203]

@Greedquest, may I ask how you’re using the API?

[Greedquest]

@rubberduck203 Just toying around with inheritance, using RD to look at what methods different classes have as an alternative to using interfaces, very much a WIP.

[bclothier]

@Greedquest I'm glad to know that there's at least one user.

As mentioned, the main problem is the lack of maintenance. Truthfully, I have no idea how much of API is still working, and how much of it is outdated due to the changes we've been making to the rest of the ducky. We also don't have a good unit test coverage -- for a while it has been assumed that it was basically untestable but I think it can be tested via COM marshaling to at least approximate VBIDE. And as noted, API is missing some features that would make it more useful (e.g. exposing DeclarationFinder). All that needs a maintainer. Right now, we don't have enough contributors to keep up.

If someone wants to take it up, we're all for it. The simple fact is that everything has a cost, and the pieces that aren't adequately covered/used costs more because it can impede changes in the rest of codebase.

[Vogel612]

Part of why the API is so unmaintainable is the difficulty of wiring up the parser. As it stands, for Rubberduck's internal needs we're wiring up the parser with CW. The API is manually wired up, though. This means that changes to how the parser works and is internally functioning need to be mirrored in the manual parser setup for the API, which is... not ideal.

We might be able to make good use of CW for the API if we can wire up the parser and only the parser to expose it. This would simultaneously decrease the maintenance burden for the API and could help making the RubberduckIoCInstaller more ... accessible to a wider range of contributors.

[rubberduck203]

So you’re not using it for any kind of production workload. That’s good to know.

I would call our that Git integration wasn’t killed because there were other good options (there really aren’t IMO, although there are acceptable ones), but due to lack of a maintainer to support the feature.

Ultimately this is about cost vs. the benefit it brings to the community. All things considered, Git integration is of a much higher benefit to the community than the parser API, but perhaps the parser API is more in line with the project’s goals. I could see arguments either way, but it’s moot without a user base and maintainer. Supporting a little used feature is costly for a small open source community.

I would kill it, at least until someone from the community shows a real need and willingness to support it properly. Software is soft. We can always reverse the decision at a later date.

[retailcoder]

@Greedquest the API will officially unship when #5173 is merged into [next], however note that a branch was just created off current-[next], named RubberduckAPI; this branch will remain untouched and unmaintained; as @bclothier said in chat, that project makes a great example of how to do COM interop in C# - the DLL can still be built off that branch if needed.