Add module invoking to the DrupalSystemInterface

Hi e0ipso,
the MockDrupalSystem::moduleInvoke() is not needed in the regular DrupalSystem.
What would we gain by adding it?

Ah. This sounds fun!
Tbh, so far I wrote this as "good enough for xautoload". I don't know how well it will perform for other modules. I guess it would be "use at your own risk".
Maybe if we are serious about this, it should become a dedicated library on github. Then we could add it with the composer.json with require-dev.

What is your experience so far? Do you think it already is in a decent shape, or does it need a lot of changes to be universally useful? Do you think it is fine to continue maintaining this as part of xautoload, or does this impose too many limitations?

We could leave it as part of xautoload for a while, add minor improvements like the one you suggest, and then some day in the future it could still go to github.. It just means we need to change the (unwritten) goal for this thing.

Also, if other modules start using this, we need to start worrying about API stability.
So far I can do refactoring like renaming methods and changing their behavior, without having to worry about 3rd party code.

Do you use the service container module in combination with the DrupalSystem from xautoload?
Or do you have something custom now?
I don't think you need the xautoload service container to use the mock classes in your own project..

Btw, maybe you are interested in this one: https://github.com/donquixote/d8plugin
And you should enable issues in https://github.com/mateu-aguilo-bosch/plug. Currently it seems that only PRs are enabled, but issues are not.

Regardless of that, I think it would be really beneficial to have an object oriented Drupal 7 wrapper library. That would allow module implementors to use it to inject the services they need to call any D7 core function.

Yes!
I just imagine it to be a lot of work until it is universally useful.
And there should be a consistent conversion pattern. Maybe, as a rule, 1 function = 1 class? And 1 procedural file = 1 namespace?
Not every of those needs an interface. Only those parts that are going to be used in a specific module.

If a Drupal module wants to use the interfaces from this library, e.g. DrupalSystemInterface, then it will need something like composer manager to have this stuff downloaded.
Maybe there could be two libraries: One with just the interfaces and real implementations (direct call to the Drupal procedural function), and another library with mock implementations.

Or a module could have something like DrupalSystemInterface and DrupalSystem built-in, taylored to its own use. And then a MockDrupalSystem that is defined in the module, but that uses the components provided by the library.

The goal would be to only have the dependency for testing with phpunit.