Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94649
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
To: internals@lists.php.net
References: <CAEDdnaWVYbh=t1-bvDh9fixCoC7Be4asoEus=dRhGggx_9VLNg@mail.gmail.com>
 <8a39df34-4a23-c496-15f6-20a62d27fc59@gmail.com>
 <CAEDdnaWwUUVV6q1Sh+pXNQEAENXHHbJ=ZPaq4otnpnFPwVD-5A@mail.gmail.com>
 <CAObuZdvy9F3sLu=MArNEvh3ZxFkZ=byb7UbH0Gaw2sx=C0QRzw@mail.gmail.com>
 <CAEDdnaV8Qaoib6=v+NBCYYymtQQgyr28qryJ1dBHhVsXqWu5kA@mail.gmail.com>
Message-ID: <4920f683-9a4d-7153-b157-a7d7ce8cbfe7@gmail.com>
Date: Sat, 23 Jul 2016 16:23:52 +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: <CAEDdnaV8Qaoib6=v+NBCYYymtQQgyr28qryJ1dBHhVsXqWu5kA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; 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 22/07/2016 15:54, Michael Vostrikov wrote:
>> The more you compare it to a function call, the less I understand how it
> gains over just defining a function e() and writing <?= e( $foo, 'html') ?>
>> > I might as well just write "function e($string, $mode='html') { .... }"
>> > they will already have a method of doing this
> Yes, and they have to write a call of it everywhere. New operator can
> remove it.

This is the part I don't get. How does "using an operator everywhere" 
remove the effort of "using a function everywhere"? It's the same effort 
in both cases.


> The goal is to remove copy-paste for HTML escaping (so it will become
> automatic)
   > ...
   > the problem is to copy-paste it in 90% places of output data.

If somebody can't type "e(" and ") without copying and pasting, then 
they're going to have a hard time writing any meaningful code.


>> On the other hand, if I have an array and ask for it to be HTML-escaped,
> nothing iterates the array for me, it will just print "Array". So if I ask
> for it to be "JS-escaped", why should it magically produce a JSON array?
> Yes, I agree, I methioned this in RFC - JSON is not escaping, it is
> encoding in special notation.
> This is one of the reasons why I was disagreed with the need to support
> multiple contexts.
> So, the question is up again - do we really need multiple contexts?

The reason multiple contexts are needed, in my opinion, is the false 
sense of security of saying "we have built-in escaping", but actually 
meaning "we have built-in HTML escaping". If the idea of this feature is 
to make good escaping habits second-nature to users who don't have a 
templating system, then there's a responsibility to remind them that not 
all contexts are created equal.

As for what "JS-escaped" should mean, why not just backslash-escape 
quote marks, like you'd ampersand escape double quotes in HTML?

<?php $foo = "World's End"; ?>
var foo='<?*js= $foo ?>';

var foo='World\'s End';


> Yes, PHPEscaper from RFC works that way - PHPEscaper::registerHandler().
> But it think runtime definition with second variable is more flexible way.
> There are external contexts (HTML is one of) and internal task-dependent
> contexts which can be combined with HTML. We cannot know all possible tasks.
> And we come again to pipe operator and twig-like syntax.

More flexible to what end? Why do I need to be able to dynamically 
define arbitrarily complex expressions as the filter name?

Note that what is defined in the RFC currently is *not* similar to 
Twig/Smarty, because it views the parsing of the | as *internal* to the 
callback, not part of the escaping syntax itself. It allows you to 
define an escape callback that instead uses "," as the separator, and I 
don't see why that would ever be necessary.

If you have a new context, give it a name, and register it. As I say, 
this is how streams work - you don't register a callback that filters 
all filepath strings, you register a prefix for your particular stream type.


Again, the stated aim of this RFC is to make correct escaping easier 
than incorrect escaping. That means providing really obvious syntax, out 
of the box, for doing the right thing.

Regards,
-- 
Rowan Collins
[IMSoP]