On 22/07/2016 15:54, Michael Vostrikov wrote:
The more you compare it to a function call, the less I understand how it
gains over just defining a function e() and writing <?= e( $foo, 'html') ?>
> I might as well just write "function e($string, $mode='html') { .... }"
> they will already have a method of doing this
Yes, and they have to write a call of it everywhere. New operator can
remove it.
This is the part I don't get. How does "using an operator everywhere"
remove the effort of "using a function everywhere"? It's the same effort
in both cases.
The goal is to remove copy-paste for HTML escaping (so it will become
automatic)
> ...
> the problem is to copy-paste it in 90% places of output data.
If somebody can't type "e(" and ") without copying and pasting, then
they're going to have a hard time writing any meaningful code.
On the other hand, if I have an array and ask for it to be HTML-escaped,
nothing iterates the array for me, it will just print "Array". So if I ask
for it to be "JS-escaped", why should it magically produce a JSON array?
Yes, I agree, I methioned this in RFC - JSON is not escaping, it is
encoding in special notation.
This is one of the reasons why I was disagreed with the need to support
multiple contexts.
So, the question is up again - do we really need multiple contexts?
The reason multiple contexts are needed, in my opinion, is the false
sense of security of saying "we have built-in escaping", but actually
meaning "we have built-in HTML escaping". If the idea of this feature is
to make good escaping habits second-nature to users who don't have a
templating system, then there's a responsibility to remind them that not
all contexts are created equal.
As for what "JS-escaped" should mean, why not just backslash-escape
quote marks, like you'd ampersand escape double quotes in HTML?
<?php $foo = "World's End"; ?>
var foo='<?*js= $foo ?>';
var foo='World\'s End';
Yes, PHPEscaper from RFC works that way - PHPEscaper::registerHandler().
But it think runtime definition with second variable is more flexible way.
There are external contexts (HTML is one of) and internal task-dependent
contexts which can be combined with HTML. We cannot know all possible tasks.
And we come again to pipe operator and twig-like syntax.
More flexible to what end? Why do I need to be able to dynamically
define arbitrarily complex expressions as the filter name?
Note that what is defined in the RFC currently is *not* similar to
Twig/Smarty, because it views the parsing of the | as *internal* to the
callback, not part of the escaping syntax itself. It allows you to
define an escape callback that instead uses "," as the separator, and I
don't see why that would ever be necessary.
If you have a new context, give it a name, and register it. As I say,
this is how streams work - you don't register a callback that filters
all filepath strings, you register a prefix for your particular stream type.
Again, the stated aim of this RFC is to make correct escaping easier
than incorrect escaping. That means providing really obvious syntax, out
of the box, for doing the right thing.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
