Please, stop spamming us with the same comments. Cheers Joe
On Sat, 26 Jun 2021 at 14:25, Dan Ackroyd <dan...@basereality.com> wrote: > On Fri, 25 Jun 2021 at 00:57, Craig Francis <cr...@craigfrancis.co.uk> > wrote: > > > Dan Ackroyd wrote: > > > 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? > > > > By using a simple function, it allows the library to handle > > the situation however it likes. > > That's not an answer to the question. > > Just saying "you can handle it however you like" skips over the core > problem with RFC, which is that by supporting carrying the literal > flag through string concatenations, > > 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. > > For is_literal checks, what's going to happen is: > > * programmer makes a mistake, that isn't caught by a test. > * programmer deploys site, and entries about non-literal strings start > being written to log files. > * someone then needs to remember to check the log files, and pull out > the appropriate entries, and make a ticket for them to be > investigated. > * someone then needs to pick up that ticket, investigate the cause of > the non-literal string being used, and trace it back to which > module/library is causing it, then update the ticket for someone on > that team to fix it. > * someone on that team needs to have that ticket prioritised before > they start work on it. > > > I'd really like anyone who is promoting this RFC to answer the > > question from https://news-web.php.net/php.internals/115010 : > > > 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? > > It's going to take more time to track down an error than it will be to > start using the feature. > > I had planned to use this RFC to prevent XSS attacks, and in the > current implementation I'm going to get a notice of "There's some > userdata in an inappropriate place. Have fun finding it!" because the > information about where that user data is in the HTML will be lost. > > It's still bizarre to me that the RFC is proposing something that > allows mistakes to slip through to production. > > cheers > Dan > Ack > > btw, email or ticketing systems are not an appropriate place to log > this type of problem. They could happen on every page load, and so > generate hundreds of errors per second. As amusing as it is to look > back at the times that I have generated 10,000 error emails per second > in the past, I don't want to repeat that experience. > > Also, I'm going to cross-post this, as it's unreasonable to expect > people to read all of the different threads. >
