> 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
