Dynamic parameter does not work in static parameter about di HOT 27 CLOSED

It will work a little differently, instead of $container->parameters['test'] will work $container->getParameter('test').

from di.

You can reference dynamic parameters anywhere except static parameters, the same way static parameters are referenced. What you are trying to do cannot work (and should throw an exception?)

from di.

In theory it should work, it's just that the compiled DIC needs to look different.

from di.

I see your point, you just confused me with the title. Reference to a dynamic parameter in another parameter may work, esentially making the referecing parameter dynamic instead of being static

from di.

I'm looking at it and it's working properly. The documentation doesn't say that the values of dynamic variables are found in the $container->parameters array. This is an internal variable that is public only for historical reasons. But it might be possible to add a getParameter() method to make dynamic parameters available.

from di.

I did a few more tests: ondrejmirtes/nette-di-dynamic@475447b

The result of the script is now:

NULL
string(7) "foo/foo"
string(7) "foo/foo"

So when used as a service argument, it works as expected. The compiled container looks like this:

($this->parameters['env']['NETTE_TEST']) . '/foo'

It would be awesome if the parameters array could look like this too.

from di.

In other words, you want that instead of lazy evaluation, there should be immediately evaluation at the beginning. That might work, of course, but it's a trade-off.

from di.

I'm thinking there might be a compromise. Parameters like %env.NETTE_TEST%/foo can be resolved right away. Parameters that call methods like @service::foo() can continue to resolve lazy.

I tried implement it in 3.2-dev

from di.

Looks like 3.2-dev includes a lot of BC breaks (removes current features) which it should not so unfortunately I can't test it: https://github.com/nette/di/commits/v3.2

Would be great if 3.2 still supported PHP 7.2+ which is what PHPStan supports. Although I can work around that if needed.

from di.

It could probably be put into version 3.1.

Btw what problematic BC breaks did you encounter?

from di.

1. Minor versions should never contain any BC breaks.
2. nette/di is used by PHPStan users through custom .neon files so any changes to supported NEON syntax can break PHPStan for someone. I think that's the case of this commit 3b3c1ad This is also a BC break for generated factories from what I understand 5c36951.

When upgrading to nette/di 3.1.3 I also had to silence E_USER_DEPRECATED with this commit phpstan/phpstan-src@c43ac09 when creating the DI container because I don't want to bother PHPStan users with these deprecations: phpstan/phpstan-src@c43ac09 (in the future I'd probably transform the neon array on user's behalf before passing it to nette/di).

from di.

If you encounter any problems, you'd better write me and not mute E_USER_DEPRECATED.

I don't consider it as a BC break to remove things that have been throwing out E_USER_DEPRECATED since the previous version, two years old. But if you don't play the game, of course it can be a problem.

from di.

Yeah, personally I wouldn't use any deprecated things in my own applications and fix them immediately, but PHPStan exposes nette/di to its users through the neon config format, and I would have to provide some easy migration path so that my users are not bothered with these deprecations.

from di.

And which ones in particular did they encounter, do you remember?

from di.

@dg I haven't released a version that wouldn't silence E_USER_DEPRECATED from nette/di so I didn't really get that feedback, but I think the most common one is the deprecated class key for services, as can be seen very frequently in 3rd party packages like https://github.com/shipmonk-rnd/phpstan-rules/blob/master/rules.neon.

from di.

Thank you! I'm gonna try it right away.

from di.

Hmm, that's strange, class should work normally...

from di.

%env% in parameters now works as expected! 🎉 Thank you very much!

As for class in services: If I un-silence E_USER_DEPRECATED, I get many of these errors:

PHP Deprecated:  Service '9': option 'class' should be changed to 'type'. in vendor/nette/di/src/DI/Extensions/DefinitionSchema.php on line 130

It still works, but I don't want to put this burden on PHPStan users.

from di.

How is it used?

- class:: ClassName                # should work
- class:: ClassName(arg, arg)      # historically this has worked, by mistake

from di.

I just debugged it and entries like this are reported as deprecated:

	-
		class: PHPStan\Php\PhpVersion
		factory: @PHPStan\Php\PhpVersionFactory::create

	-
		class: PHPStan\Php\PhpVersionFactory
		factory: @PHPStan\Php\PhpVersionFactoryFactory::create

Which is okay but I still don't want to force PHPStan users to rewrite them :)

from di.

I'll try to find a solution...

from di.

@ondrejmirtes Wouldn't be a way to resolve this in the long run to allow deprecation notifications to be turned on? So that PHPStan users would not be bothered, but the extension developers could make the necessary changes. I believe most users don't use any things from di or neon that may change.

from di.

TBH in the long run I want a different PHPStan-specific config format, probably based on objects that work with IDE autocompletion and can be validated with PHPStan analysis 😊

from di.

@ondrejmirtes see 8fd9b4a

from di.

This new patch version 3.1.4 broke codeception tests in our app based on REMP CRM,
broke environment config:

database:
    default:
        dsn: @environmentConfig::getDsn()
        user: @environmentConfig::get('CRM_DB_USER')
        password: @environmentConfig::get('CRM_DB_PASS')
        options:
            lazy: yes

And getting error
[Exception] DB prepare error in command: 'phinx:migrate' | | Nette\DI\InvalidConfigurationException: The item 'database › default › dsn' expects to be Nette\Schema\DynamicParameter or string, object Nette\DI\Definitions\Statement given. in /var/www/crm/vendor/nette/di/src/DI/Compiler.php:293

Worked fine in the version 3.1.3.

from di.

I think it's best to open a new issue for it.

from di.

@kipanshi fixed

from di.