[RFC] New operator for context-dependent escaping

use escaping functions or any other escaper or just simply template engine as most of people does! I explained the reasons for implementing this operator in previous discussion and in the "Problem description" section of the RFC. There are many applications without template engine. 90% of output data in this applications are from database and should be HTML-escaped. This is not a "most of time unneeded" case. The number of similar discussion shows that the problem really exists.

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.

On 24/07/2016 10:42, Michael Vostrikov wrote:

register_escape_handler('foo', [$this, 'escape']); <?*foo= $something ?> Where's the problem? If you mean you want to be able to pass an actual callable as the context, what would be the point? Why would I ever write this: <?* $something, [$this, 'escape'] ?> when I could just write this: <?= $this->escape($something) ?>

Sorry, I still don't get it. <?= will still "work good but be unsafe" no matter how the correctly-escaped version looks. When somebody's typing code into their PHP "template" file, they've got to remember which symbols to type; they don't care if those symbols are an operator, a function, or a magic incantation. Look at the Wordpress documentation, it talks about "tags", which any programmer immediately recognises as function calls. So to a novice writing templates, it doesn't really matter if you say the incantation to output a variable is "<?= e($" followed by the variable name and ")?>", or "<?* $" followed by the variable name and "?>". One is 3 characters shorter, but that is the sole difference in terms of effort.

Huh? Is the word "I" copied in this e-mail, because the English language requires me to write it more than once? And if "e(" is "copied code", how is the "*" in "<?*" not also "copied code"? I get it, if you are talking about having to type "htmlspecialchars()" the whole time, but I stand by my assertion that anyone put off by typing "e()" is beyond hope.

Twig allows you to register a named "strategy" to a single callable, exactly as I am suggesting: http://twig.sensiolabs.org/doc/filters/escape.html#custom-escapers This is much more useful than a single callback that has to handle all possible strategies. You're right that Twig allows you to use a variable as the escaping strategy, although it warns that doing so defeats the intelligence of its auto-escaping mechanism. But this could still be done without allowing arbitrary expressions, or embedding syntax inside the strategy argument: <?*$strategy*html= $text ?> We don't need to handle all possible things that anyone might ever want to do. If they're doing something complex, they can implement their own way of doing it - probably by writing a templating engine, or using one of the many that already exist. Regards,