Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94678
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: <CAEDdnaVrAvMHzj=bxhp9fOEFRgJ3rY9Tn9XP0oPfYZ0EU-RrjA@mail.gmail.com>
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> <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>
To: internals@lists.php.net, michael.vostrikov@gmail.com
Message-ID: <20160724145557.D52C31A80BBD@dd1730.kasserver.com>
Date: Sun, 24 Jul 2016 16:55:57 +0200 (CEST)
Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping
From: mails@thomasbley.de ("Thomas Bley")

> <?: $a, $b ?>

php already uses ?: for ternary operator, so users get a bit confused by using it for escaping.

> <?* $a | $b ?>

this allows multiple interpretations:

<?* $a | $b ?> meaning $a context $b
<?* $a | $b ?> meaning $a | $b context 'html'

> <?* $a |> $b ?>

|> may be used by Pipe Operator rfc, if vote is successful

> if ($context == 'html') {

this is bad coding style since $context = 0 gives unexpected html escaping. The following expressions would be equal:

<?* $str, 'html' ?>
<?* $str, 0 ?>

please use:
if ($context === 'html') {
if ($context === 'js') {

> <?* $a, 'js', 'html' ?>

currently we cannot use set_escape_handler(function($str, ...$context = 'html') since variadic parameters cannot have a default value. So having second argument be any type should be fine.


Maybe add an example for using escape operator callback functions in frameworks:

public function render($template, $vars) {
  $this->setVars($vars);
  set_escape_handler(['SomeClass', 'methodName']);
  ob_start();
  include $template;
  $content = ob_get_clean();
  restore_escape_handler();
  return $content;
}


In total a good rfc everybody should be happy with.

Regards
Thomas


Michael Vostrikov wrote on 24.07.2016 11:48:

> I have written many messages already. I think, the purpose of this operator
> is clear.
> In this discussion I have come up to understanding what I would like to use.
> 
> You suggest very hard and complex solutions:
> 
> <?*js*html= $str ?>
> <?php['html']: ?>
> $escape = new SplEscaper; $escape->support('e', function () { ... });
> declare('filter=htmlentities');
> 
> This is not what I wanted to suggest.
> 
> 
> I have rewritten RFC a little. There is no tricks with ZEND_NAME_NOT_FQ,
> there is no magic constants, there is no problems with autoloading. The
> soultion is small, simple, and customizable.
> https://wiki.php.net/rfc/escaping_operator
> 
> 
> There are 3 functions:
> callable|null set_escape_handler(callable $handler)
> bool restore_escape_handler()
> escape_handler_call(mixed $string, mixed $context)
> 
> They work similar to set_error_handler() / restore_error_handler().
> 
> 
> Operator is compiled into the following AST:
> echo escape_handler_call(first_argument, second_argument);
> 
> Function escape_handler_call() just pass given arguments into user-defined
> handler. Second argument is not required. If the handler is not set, it
> throws an exception. There is no default handler for any context, to
> prevent 'built-in' wrong work of <?* $str ?> constructions in non-HTML
> contexts like CSV. This is not hard to create a handler once. Default
> context can be set in it as default value for second argument.
> 
> set_escape_handler(function($str, $context = 'html') {
>    ...
> });
> 
> 
> 
> What is under discussion:
> 
> Starting sign.
> Last one is more comfortable to type.
> 
> <?* $a, $b ?>
> <?: $a, $b ?>
> 
> 
> Separator sign.
> Maybe it should differ from standard <?= $a, $b ?> syntax to prevent
> mistakes like <?= $a, 'html' ?> instead of <?* $a, 'html' ?>. '|' won't
> give error, but looks more similar to escaping in template engines.
> 
> <?* $a , $b ?>
> <?* $a | $b ?>
> <?* $a |> $b ?>
> <?: $a : $b ?>
> 
> 
> If to wrap functions in a class or namespace (fully qualified), to not
> clutter up a global namespace:
> 
> set_escape_handler()
> restore_escape_handler()
> escape_handler_call()
> 
> PHPEscaper::setEscapeHandler()
> PHPEscaper::restoreEscapeHandler()
> PHPEscaper::escapeHandlerCall()
> 
> And also any names in source code or details of implementation, without
> changing main algorithm.
> 
> 
> What is not under discussion:
> 
> Built-in contexts.
> Because escape_handler_call() is not an escaper itself, but just a helper
> to call user-defined escaper, it should not handle any contexts. This
> allows to prevent 'built-in' wrong work of <?* $str ?> constructions in
> non-HTML contexts like CSV.
> 
> Multiple arguments.
> <?* $a, 'js', 'html' ?>
> I think, it is enough that second argument can be of any type, e.g. an
> array.
> 
> Complicated syntax like <?*html*js= $str ?>.
> If we allow custom handlers, then we need runtime processing, so the
> example above cannot be compiled into
> <?= htmlspecialchars(json_encode($str)) ?>
> directly, and it will something like
> <?= escape_handler_call(escape_handler_call($str, 'html'), 'js') ?>
> I.e. we anyway need to pass context as a second argument, so why not allow
> user to do it.
> 
> 
> If someone wants more complex solution or built-in template engine, he can
> create another RFC and suggest his own implementation.
>