On Thu, 24 Jun 2021 at 19:12, Joe Watkins <krak...@gmail.com> wrote: > > we're not > talking about a function that protects you from all possible security > concerns or bugs.
I know. We're talking about something that is meant to protect programmers against silly mistakes. And this RFC doesn't do that. It allows silly mistakes to slip through and make it to production. As per https://news-web.php.net/php.internals/114858: > Assume that both UserPreferences and getInfoPanel code is covered by > unit tests. The developer who made that change would run the tests, > see the tests pass and then push their code live. At which point, it > would cause an error in production, as the string returned would not > pass the is_literal check. I'd really like anyone who is promoting this RFC to answer the question from https://news-web.php.net/php.internals/115010 : > Please can you go into some detail about what you think people are > meant to do when they detect a non-literal used where a literal is > expected? There is a whole load of hand waving going on of "you can protect yourself!" but then no detail of what this RFC proposes people actually do, which means people can't evaluate whether it's worth adding or not. I know not carrying the literal flag through string concatenation would make this slightly harder to use. But that would come with lower long term maintenance, and less mistakes getting through to production. For security concerns, that seems a good tradeoff to make. I'd also quite like an answer to the following: > Why are you prioritising speed of adoption, over reducing the cost of > using this feature for projects over say the next 5 or 10 years? I think this feature should be of most value to teams with large code-bases, where maintaining the code (and figuring out security problems) has a much higher cost than for small code-bases, where this feature might not deliver much value. But by carrying the literal flag through on string concat, that results in it being annoying to use for teams with large code-bases....which seems self-defeating. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
