Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94728
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.68 as permitted sender)
To: internals@lists.php.net
References: <CAEDdnaWVYbh=t1-bvDh9fixCoC7Be4asoEus=dRhGggx_9VLNg@mail.gmail.com>
 <CAObuZdvy9F3sLu=MArNEvh3ZxFkZ=byb7UbH0Gaw2sx=C0QRzw@mail.gmail.com>
 <CAEDdnaV8Qaoib6=v+NBCYYymtQQgyr28qryJ1dBHhVsXqWu5kA@mail.gmail.com>
 <4920f683-9a4d-7153-b157-a7d7ce8cbfe7@gmail.com>
 <933449d0-90c2-0d7a-cb80-a171289d8286@texthtml.net>
 <CAGovj_PiUjJmAncZjrtTiJmBTmuwA1MgfpjwpkKWdp_NHPekpw@mail.gmail.com>
 <CAEDdnaWEwNH-+kOxPk2GDqRod90kOqbT1yGHkOMqx5L9AXRaLA@mail.gmail.com>
 <CAEDdnaVrAvMHzj=bxhp9fOEFRgJ3rY9Tn9XP0oPfYZ0EU-RrjA@mail.gmail.com>
 <20160724145557.D52C31A80BBD@dd1730.kasserver.com>
 <6cfac572-9982-87f8-5a55-9213d978cde9@gmx.de>
 <20160724162103.BC5741A83512@dd1730.kasserver.com>
 <efdfdd99-77d9-f722-7000-13b4528dd77c@gmx.de>
 <20160724172131.675AC1A800B0@dd1730.kasserver.com>
 <9bc0db6a-fa19-5f87-0e82-3702dcb34254@gmx.de>
 <CAEDdnaWm-fUoBRdrce=DF8By6ybkTe_ca_niV2xdQp4yecU6Rw@mail.gmail.com>
 <CAEDdnaVx2Rx0pe+ZCzP=rpWW8OiQ73opmRhLCho_MwV1NRAiaw@mail.gmail.com>
Message-ID: <ebfd0e1b-049f-d38b-7de8-62a98c1c2376@gmail.com>
Date: Wed, 27 Jul 2016 21:57:45 +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: <CAEDdnaVx2Rx0pe+ZCzP=rpWW8OiQ73opmRhLCho_MwV1NRAiaw@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 26/07/2016 14:15, Michael Vostrikov wrote:
> Ok. Just ask you, why people ask the same question again since the time PHP
> was created? Why almost all feature requests mentioned in RFC are about an
> easy way to call htmlspecialchars()? You can vote up or down, I just want
> to get an official result about this feature. I think, it can be considered
> as official answer to community, to those people from community who would
> like to use default escaping mechanism in PHP.

Hi Michael,

I think you and I are mostly going in circles at this point, so I'm 
going to refrain from blow-by-blow responses and sum up my thinking on 
this RFC.

Overall, I think there is some merit to the idea, but I think the detail 
is important.

The aim in my mind would be to make escaping easier to do right, for 
people who aren't already using a framework or templating engine with 
its own solution.

- Without an actual implementation, the feature wouldn't be useful to 
those people.
- Configurability should be a long way down the list of priorities, for 
the same reason.
- I think contexts other than HTML should be included to remind users 
that they exist, but HTML could be the default.
- Contexts should be stackable/nestable, *without the user writing any 
extra code*.
- The syntax should be easy to read as well as easy to write. How easy 
it is to implement is a low priority.

The current implementation doesn't seem to share these priorities; it 
feels like a building block for framework developers, who probably have 
their own solutions already.


A few mentions have been made of Twig, which is known for its 
comprehensive escaping support; it goes a lot further than the fact that 
"|e" is an alias for "|escape('html')":

- you can define automatic escaping for a whole file or a block within a 
file
- there is an extra filter to skip the automatic escaping (not the same 
as unescaping)
- the above can be done with any "context", but the default is HTML
- a "context" is not just the argument to a single all-powerful "escape" 
function; you can register a new context by name, without reimplementing 
any of the existing functionality
- other template functions can say that their output shouldn't be 
escaped, or that their input should be pre-escaped
- other functionality of the system is aware of these notions, and 
designed to behave sensibly

I don't think there's any way PHP can ever reach that level of 
sophistication, because most of the language knows nothing about 
"context"; the feature we build in is only ever going to be a simple 
short-hand for some basic function calls.


In many ways, defining a built-in function e($string, $context) would 
fulfil most of the above. A dedicated syntax might make it a little 
easier to type, and could handle nested contexts more elegantly. The 
ability to register additional contexts and take advantage of the syntax 
and nesting could be a simple addition. Any more complicated than that, 
and you're fighting a losing battle against dedicated templating engines.

That's my opinion, anyway. It is just an opinion, and you're free to 
disagree with it, but hopefully my reasoning is clear.

Regards,

-- 
Rowan Collins
[IMSoP]