Writing plugins and using internal classes

[pilif]

I'm in the process of updating our decade-old codebase from psalm 4.30 to psalm 5.1.0.

To help psalm with some of our legacy type-system, let's call them hacks, we employ a few plugins to mark methods as used and some return type provider.

However, now in psalm 5, I noticed that many classes we were using in the plugins, like \Psalm\Internal\MethodIdentifier moved to @internal which now of course causes plsalm to raise InternalClass issues.

What's the best practice for writing plugins? In this case, this happens in an afterMethodCallAnalysis method where I'm trying to get to a MethodStorage through $event->getCodebase()->methods->getStorage() but that needs a MethodIdentifier which I'm now told I shouldn't be instantiating.

So the question is:

• do I move my plugins into \Psalm\Internal (feels wrong)?
• do I add a suppression (doing this ATM - also feely yuck)?
• am I using the wrong API (though tbh, stuff reachable from an argument to an official plugin method should not rely on internals)?

[danog]

Hmm, Codebase provides multiple method used to work with indirectly with method storages, why exactly do you need to fetch the storage instead of for example its parameters (Codebase::getMethodParams) or its return type (Codebase::getMethodReturnType)?

[pilif]

It varies. In some cases, I'm just calling __toString() on it for later usage with addMethodParamUse() or methodExists() - these I could of course handle by just re-implementing what MethodIdentifier::__toString() does, but that feels equally wrong.

In one case, I'm needing defining_fqcln and cased_name on the storage, so here there's no way around needing the MethodIdentifier.

[orklah]

Honestly, the whole plugin API would need to be extracted, documented and clarified... (We don't really have a plugin API in fact, it's using internal functions mainly...)