Eliminate the need for an autoloader (`services.yml`) to know about the Internal layer about composer-stager

[TravisCarden]

@mxr576, have you ever had to deal with this--a class autoloader needing to know about your internal/infrastructure layer, and by extension, external client projects depending on it?

[mxr576]

Thanks for the ping, I am definitely interested. I'll try to understand the problem and share my 2 cents.

[mxr576]

My first impression after 3 minutes: am I missing the application/use case layer in PhpTuf\ComposerStager that would contain classes with explicit use case implementations?
Like \PhpTuf\ComposerStager\API\Core\CleanerInterface is an API... but the only available implementation is internal at \PhpTuf\ComposerStager\Internal\Core\Cleaner.

The same for \PhpTuf\ComposerStager\Internal\Core\Beginner which is used why DIC by \PhpTuf\ComposerStagerConsole\Console\Command\BeginCommand.

IMO, use cases should be public, part of the API and BC promise in a library like ComposerStager; those are executed via presentation layer codes, like this console command.

[TravisCarden]

Thanks, @mxr576. As an API-only library, Composer Stager is application agnostic--like Symfony components, for example. Drupal Automatic Updates is the canonical application, and Composer Stager Console is another.

Are you suggesting that the internal core classes (\PhpTuf\ComposerStager\Internal\Core) are effectively use cases that should be in their own separate, public layer instead? If so, how do you protect external applications from implementation changes in them? And wouldn't that just shift the problem? In other words, if a use case class needs to use PhpTuf\ComposerStager\API\FileSyncer\Service\FileSyncerInterface (API), wouldn't the autoloader still need to know about PhpTuf\ComposerStager\Internal\FileSyncer\Factory\FileSyncerFactory (internal)?

[mxr576]

Still scratching the surface of the code... so consider that when you read my answer.

Composer Stager is application agnostic--like Symfony components

👍 If Symfony would not be in a sentence and would only appear as optional dependencies, it would be even cooler. But sometimes, based on costs & benefits, relying on external components is the better choice.

I found it extremely strange that the only public components of ComposerStager under PhpTuf\ComposerStager\API are interfaces and exception classes. What are the benefits of a library that only has opinions without actual solutions?

Are you suggesting that the internal core classes (\PhpTuf\ComposerStager\Internal\Core) are effective use cases that should be in their own separate, public layer instead?

Probably yes, and even more... What is the risk being marking \PhpTuf\ComposerStager\Internal\FileSyncer\Service\PhpFileSyncer or PhpTuf\ComposerStager\Internal\FileSyncer\Factory\FileSyncerFactory or \PhpTuf\ComposerStager\Internal\Process\Service\Process (or at least the related factory \PhpTuf\ComposerStager\Internal\Process\Factory\ProcessFactory) as part of the public API? They are implementations of well-defined contracts that constrain them and they are also covered by tests.

If so, how do you protect external applications from implementation changes in them?

Since contracts (interfaces) describe the expected behaviors, dependent codes should not/must not care about implementation changes until those remain compatible with the contract. If there were serious oversight in designing a contract and related implementations, then changing the contract will create a new major version and that is fine; that is the expected way of software evolution.
In the case of use cases, they can only change in a BC way, or else a new use case needs to be defined that may replace the existing one in a new major version. There could be multiple use cases provided by a library for a problem in the same problem space. Like a synchronous and asynchronous use case implementation for compiling SCSS files...

And wouldn't that just shift the problem? In other words, if a use case class needs to use PhpTuf\ComposerStager\API\FileSyncer\Service\FileSyncerInterface (API), wouldn't the autoloader still need to know about PhpTuf\ComposerStager\Internal\FileSyncer\Factory\FileSyncerFactory (internal)?

So one part, ComposerStager can provide already identified use cases as part of its public APIs with implementations for use case implementations. Because their dependencies also become part of the public API (and they usually implement a contract, right?), so if it becomes necessary, then consumers of the library can also put together their own use cases and rely on interfaces from this library and valuable implementations for those.

[TravisCarden]

Thanks for your input, @mxr576! I'll have to give it some thought. In the meantime, I was able to solve the particular problem in this issue (PR above) without significant redesign.

[mxr576]

@TravisCarden I am glad it got resolved quickly and thanks for the ping! I hope you did not regret based on my feedback, I hope I was not harsh. This is an interesting and high quality project, I like getting back to it time after time.

This thread and the fix for the problem also proved my assumption that I am I've been cherishing for a long time: Without a DIC or a service locator that can bypass layering rules, it is really complicated or kinda impossible to keep them implemented by the book. Something MUST initiate objects and inject them in the place of contract dependencies.

[TravisCarden]

I hope you did not regret based on my feedback, I hope I was not harsh.

I always appreciate your feedback, @mxr576, and I didn't take you to be harsh at all. 🙂

This is an interesting and high quality project, I like getting back to it time after time.

Thank you! 😄

Without a DIC or a service locator that can bypass layering rules, it is really complicated or kinda impossible to keep them implemented by the book.

My experience on this project has led me to the same conclusion. That's why it's the only approach that's officially supported. That leaves me with complete freedom to do even major refactoring in the Internal layer without breaking contracts. As long as I depend exclusively on interfaces, anyone could replace my implementations or decorate them, but since they can't subclass them, they can't depend directly on any implementation details.