Re: [RFC] New operator for context-dependent escaping

> Then why is absolutely everything in the current RFC optional and > configurable to the Nth degree? It's one handler: set_escape_handler() (N=1) Currently, every framework has it's own methods for escaping. To get this together, set_escape_handler() is a good choice, similar to set_error_handler(). > OK, so I can dynamically redefine the same syntax to mean different > things at different times, within the same application. I'm not entirely > sure that's a particularly good thing. It's the same thing with set_error_handler(), set_exception_handler(), spl_autoload_register(), error_reporting(), etc., this concept is proven to work. > In my opinion, they are central to the feature, not an optional extra. maybe you can join the rfc and provide the implementation? Regards Thomas Rowan Collins wrote on 24.07.2016 19:41: > On 24/07/2016 18:06, Thomas Bley wrote: >>> It's not that difficult to write a static analyser that detects >>> instances of "<?=" not followed by "h(" or "e(" or >>> whatever. >> <?* and <?= are same for all applications, h() is user-defined. So you need to >> write a different analyzer for every application if you use h() or e(). > > This argument is only valid if the RFC includes an implementation, not > just a syntax. As currently proposed, not even the syntax would be the > same for all applications, as part of it is hand-waved as up to whoever > writes the escape callback. > > >>> Surely the feature gets most of its value from what you *don't* need to >>> do - which is why I think it's bizarre that the current version doesn't >>> even have a built-in HTML escaper at all. >> I think it's no problem to have a follow-up rfc defining some default >> escapers. > > In my opinion, they are central to the feature, not an optional extra. > > >> >>> It's not possible for multiple frameworks or libraries to declare >>> different escape handlers in your proposal, either. >> not sure I get your point? >> >> public function render($template) { >> set_escape_handler(['SomeClass', 'methodName']); >> ob_start(); >> include $template; >> $content = ob_get_clean(); >> restore_escape_handler(); >> return $content; >> } > > OK, so I can dynamically redefine the same syntax to mean different > things at different times, within the same application. I'm not entirely > sure that's a particularly good thing. > > >>> You could equally say, "with <?=e()?> you have to define an e() >>> function". The main effort is remembering to use the right syntax, which >>> you have to do either way. >> the thing here is that people can use <?= without e() and save coding time. > > People can use <?= instead of <?* and save learning the difference. Lazy > people will still be lazy. > > Yes, there's a very slight effort saved by it being shorter, but at the > cost of a minimum PHP version, an extra thing to learn, etc. > > >> Security cannot be optional, see. > > Then why is absolutely everything in the current RFC optional and > configurable to the Nth degree? > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >