di

di copied to clipboard

We should Identify all cases when ? is used, resolve them and remove a question mark (it is like eval).

So hypothetically... what should I use instead of

->addSetup('$service->methodA(?)->methodB(?)', ['a', 'b']);

->addSetup([new Statement('@self::methodA', ['a']), 'methodB'], ['b']);

Yep, that's what I was afraid of. :-1:

Why :-1:? Is it forbidden to invent some syntactic sugar? Like chain('@self::methodA', ['a'], 'methodB', ['b'])?

First its a BC break that would force me to update quite a few of my extensions. Second the syntax using question marks is probably the best syntactic sugar you could come up with - the chain syntax from your last comment doesn't solve cases like @a->b(@c->d(?)). Also this would effect neon definitions as well right?

By the way you didn't mention why you want to remove the question marks in the first place. Right now I fail to see any benefit, only BC break and uglier syntax. Thats why :-1: for now but you might be able to convince me.

Because eval is evil. DI compiler is unable to understand what it means. It relies on internal implementation details, like name $service etc…

$service can be replaced with @self right?

@dg I'm strongly against removing the ability to push custom code to the service creation. It's very handy and allows for hacking the container :)

I've went through most of my code, and the main reason for using the ? is appending to an array. So adding a syntax like this would be neccesary

$def->addSetup('$array[]', ["value"])
# converts to
$service->array[] = "value";

Imho it makes sense first to introduce new syntaxes to solve the causes for using the ? and remove/depricate it much longer after it's adopted.

@fprochazka see https://github.com/nette/di/pull/93#issue-129077391

@dg "eval is evil" is a statement taugh to begginers because they can create a lot of damage by using it wrong and also create exploits. It's not evil, just dangerous.

@dg I never figured the array in setup's statement, that's a nice one.

new syntaxes to solve

I think it can be solved with current syntax (::array_push(@self::$array, value) in neon), but I am opended to enhance syntax.

@dg I get your point, but I hope I'm not the only one who considers this very ugly :)

My use-cases for custom code in service creation

• Clock/DI/ClockExtension.php ... hope you won't deprecate this one :)
• Console/DI/ConsoleExtension.php this could be replaced by array append and some static function
• Console/DI/ConsoleExtension.php this by better compile-time analysis of the service, but mainly array append
• Doctrine/DI/OrmExtension.php for reusing the variable later, this can be refactored easily
• Doctrine/DI/OrmExtension.php chaining, can be refactored with https://github.com/nette/di/pull/93#issuecomment-175505537
• Facebook/DI/FacebookExtension.php array prepend... could be solved by introducing a method I guess
• Facebook/DI/FacebookExtension.php array append
• Google/DI/GoogleExtension.php there was a cyclic dependency in the original library
• HtmlValidator/DI/ValidatorExtension.php array append
• Translation/DI/TranslationExtension.php array append

There is more, but this represents the most common ones for me.

@dg please reconsider the BC Break effect of deprecating this on extensions. I'm :+1: on adding the new syntax for array append, but :-1: on removing the ?.

It may be interesting to use https://wiki.php.net/rfc/use_function#domain_specific_languages combined with https://wiki.php.net/rfc/group_use_declarations#rfc_impact instead of parsing magic strings.

@JanTvrdik nice idea

Perhaps the solution would be to introduce less magic syntax, for example

		setup:
			- '$service->onClick[] = ?'([@self, 'method'])  # old way
			- ?php('$service->onClick[] = ?', [@self, 'method'])  # new way

			- method('? + ?'(1, 2))  # old way
			- method(?php('? + ?', 1, 2)) # new way