Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.128.151 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <fee7cd80-0da9-6c92-0783-1d6f54ecaa17@gmail.com>
References: <20160724170644.916231A8060C@dd1730.kasserver.com><fee7cd80-0da9-6c92-0783-1d6f54ecaa17@gmail.com>
To: internals@lists.php.net, rowan.collins@gmail.com
Message-ID: <20160724180950.E1D6B1A8066E@dd1730.kasserver.com>
Date: Sun, 24 Jul 2016 20:09:50 +0200 (CEST)
Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping
From: mails@thomasbley.de ("Thomas Bley")

> 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
>