Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94688
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: internals@lists.php.net
References: <20160724170644.916231A8060C@dd1730.kasserver.com>
 <fee7cd80-0da9-6c92-0783-1d6f54ecaa17@gmail.com>
 <20160724180950.E1D6B1A8066E@dd1730.kasserver.com>
Message-ID: <d6dc43cc-53a9-1285-0331-2a6d51b70b6e@gmail.com>
Date: Sun, 24 Jul 2016 19:29:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160724180950.E1D6B1A8066E@dd1730.kasserver.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping
From: rowan.collins@gmail.com (Rowan Collins)

On 24/07/2016 19:09, Thomas Bley wrote:
>> 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().

It's not set_escape_handler() that I'm concerned about, it's how you 
actually use it in the templates. At the moment, the only thing the RFC 
actually asserts about the escape handler is "it's a function with two 
arguments". Frameworks are free to write all sorts of weird shit:

<?* $foo, 'html' ?>
<?* 'html', $foo ?>
<?* $foo, 'text/html' ?>
<?* $foo, [$this, 'escaper'] ?>
<?* $foo, $this ?>
<?* $foo, 'js | html' ?>
<?* $foo, 'js + html' ?>
<?* $foo, ['js', 'html'] ?>
<?* $foo, '[js, html]' ?>
<?* $foo, '{js, html}' ?>
<?* $foo, 'html(UTF-8)' ?>
<?* $foo, 'UTF-8' ?>
<?* [$foo, $bar, $baz], 'ul > li' ?>
etc
etc

If you want to provide something that will be the same in all 
frameworks, then you've got to actually provide it.


>> 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.

OK, fair enough. I'm not sure it's really a killer feature, though. The 
fact that I can't easily redefine "function e()" is no more of a problem 
here than anywhere else in the language.


>> In my opinion, they are central to the feature, not an optional extra.
> maybe you can join the rfc and provide the implementation?

The implementation I'm talking about is hardly complex, just some 
default arguments to htmlspecialchars(). Or that would be the case, if 
we didn't need to provide one escape callback to handle all possible 
arguments, rather than registering for a specific strategy name.

Regards,

-- 
Rowan Collins
[IMSoP]