ContainerBuilder: removed support for ? (BC break)

[dg]

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

[enumag]

So hypothetically... what should I use instead of

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

[dg]

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

[enumag]

Yep, that's what I was afraid of. 👎

[dg]

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

[enumag]

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 👎 for now but you might be able to convince me.

[dg]

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

[enumag]

$service can be replaced with @self right?

[fprochazka]

@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.

[dg]

@fprochazka see #93 (comment)

[fprochazka]

@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.

[fprochazka]

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

[dg]

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.

[fprochazka]

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

[fprochazka]

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 ContainerBuilder: removed support for ? (BC break) #93 (comment)
• 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.

[fprochazka]

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

[JanTvrdik]

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.

[fprochazka]

@JanTvrdik nice idea