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
