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

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]