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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
