ContainerBuilder: removed support for ? (BC break)#93
ContainerBuilder: removed support for ? (BC break)#93dg wants to merge 2 commits intonette:masterfrom
Conversation
|
So hypothetically... what should I use instead of ->addSetup('$service->methodA(?)->methodB(?)', ['a', 'b']); |
|
|
|
Yep, that's what I was afraid of. 👎 |
|
Why 👎? Is it forbidden to invent some syntactic sugar? Like |
|
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 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. |
|
Because eval is evil. DI compiler is unable to understand what it means. It relies on internal implementation details, like name |
|
|
|
@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 $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 |
|
@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. |
I think it can be solved with current 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
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 👍 on adding the new syntax for array append, but 👎 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 |
ba7b241 to
fb96e4f
Compare
231a29c to
7f12a9f
Compare
9fbd1d4 to
a71f267
Compare
5d38530 to
c005bde
Compare
9f20091 to
5a589e2
Compare
7c89b37 to
e00a9be
Compare
539908c to
9e31491
Compare
b1bf33b to
abfbe74
Compare
5860223 to
f5d91ca
Compare
|
Perhaps the solution would be to introduce less magic syntax, for example |
We should Identify all cases when
?is used, resolve them and remove a question mark (it is like eval).