Translator factory has hidden dependency on laminas/laminas-cache-storage-deprecated-factory

[rieschl]

Bug Report

Q	A
Version(s)	2.28.0

Summary

We cleaned up our composer dependencies and removed the laminas/laminas-cache-storage-deprecated-factory because there weren't any usages in our code.
After that, the factory of the Translator exploded because it tries to instantiate the cache for the translator with the StorageFactory from said package.

Current behavior

The application explodes because \Laminas\Cache\StorageFactory cannot be found.

How to reproduce

Add

    'translator' => [
        'cache' => [
            'adapter' => [
                'name' => \Laminas\Cache\Storage\Adapter\Memory::class,
            ],
        ],
    ],

to the config and try to pull \Laminas\I18n\Translator\Translator from the container or build it with Translator::factory($options) where $options is the above array inside the translator key.

Expected behavior

No boom 🙂
I think either the dependency should be added to the require section and not require-dev or the factory should use the new StorageAdapterFactoryInterface(?) instead of the deprecated one.

[froschdesign]

I think either the dependency should be added to the require section and not require-dev or the factory should use the new StorageAdapterFactoryInterface(?) instead of the deprecated one.

The problem is the soft dependency on laminas-cache. If laminas-cache is not needed then the deprecated factory is also not needed.
This will be solved with the next major version because the soft dependencies are crap. And caching in general should not be integrated in the translator or in a paginator.

[ramchale]

In the meantime is it worth adding a warning to Translator?

Something like

        if (isset($options['cache'])) {
            if ($options['cache'] instanceof CacheStorage) {
                $translator->setCache($options['cache']);
            } else {
                trigger_error('Constructing the cache in the Translator will be removed in a future release. Please pass a StorageInterface instance.', E_USER_DEPRECATED);
                $translator->setCache(Cache\StorageFactory::factory($options['cache']));
            }
        }

[gsteel]

Ideally, the soft dependencies should be made hard dependencies - symbols are used in src therefore the dependency should be declared (And removed in the next major), but, triggering a deprecation seems like a good middleground.

WDYT @froschdesign?

[froschdesign]

…triggering a deprecation seems like a good middleground.

The documentation must also be modified for this, because if a user follows a description in the documentation, no error message should be triggered.

Related to: https://docs.laminas.dev/laminas-i18n/translator/factory/#using-cache-configuration

---

But this also means that a currently running laminas mvc-based application that uses the configuration for the translator triggers this error. This creates extra work on the user side (e.g. creating a delegator) or at least anger and frustration.

[gsteel]

The documentation must also be modified for this

So, perhaps documentation first, followed by a patch to introduce the deprecation. That way, the deprecation message can link to the updated documentation with a full explanation.

[gsteel]

And caching in general should not be integrated in the translator or in a paginator.

Also, I assume that this comment means that translators should be decorated with extra functionality, i.e. CachingTranslator implements TranslatorInterface?

[froschdesign]

And caching in general should not be integrated in the translator or in a paginator.

Also, I assume that this comment means that translators should be decorated with extra functionality, i.e. CachingTranslator implements TranslatorInterface?

Right, this would open the door to add more features and also on the user side. The translator itself is reduced to a message loader and a message formatter (both can be plugin managers). Everything else can be decorators.