Re: [RFC] New operator for context-dependent escaping

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

Operator is compiled into the following AST: echo escape_handler_call(first_argument, second_argument);

I'm sorry, but this is now so simple it undermines its own argument for existing.

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.

So it is now mandatory to have some bootstrap file somewhere that defines and registers the escape function? How is that different from writing, right now, at the top of your bootstrap file: function e($str, $context = 'html') { ... } You are effectively offering a way of aliasing a particular function to the magic name "*", and everything else is still down to the user.

Complicated syntax like <?*html*js= $str ?>.

I have no idea why that is "complicated syntax", but your proposal isn't: <?: $str | 'html | js' ?> Or even: <?: $str | ['html', 'js'] ?> In your proposal, part of the syntax won't even be standard between different people's code (and yes, the '|' in 'html | js' is syntax, even if it's not parsed until run-time). Is it just that you don't like the escape strategy coming first? I suggested it that way just to make it stand out more, but this would be entirely equivalent (assuming we could find an appropriate separator): <?* $str : html : js ?>

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') ?>

Yes, this is exactly how all template languages I've ever seen do it. Once you unroll the if / switch / lookup table, the code run under your proposal would be something like this: $temp = $str; $temp = json_encode($temp); $temp = htmlspecialchars($temp); I don't really see how one is any better than the other.

I.e. we anyway need to pass context as a second argument, so why not allow user to do it.

Because we're trying to make it easier for the user, not harder. Why make them handle the nesting, sanity-checking, and control flow of multiple filters, rather than building them into the syntax from the start? Regards, -- Rowan Collins [IMSoP]