I've read your RFC, and I think this a strange feature.
All it is, really, is a registry for functions, and syntactic sugar for
calling those functions - it's unnecessary, it's more global state you have
to manage, and it's the kind of superficial convenience that will end up
breeding more complexity.
What's also strange, is the ability to call functions in this registry
hinges on syntax. What if I want to call the registered functions from
within code?
ob_start();
?><* $text *><?
$html = ob_get_clean();
Yikes.
To quote a few phrases from the RFC:
> Both variants <?= h($something) ?> and <?= $something ?> work good.
This is so true - and the whole syntactic convenience line of thinking
really should end with that.
> Also there is a problem with function autoloading.
I maintain that this is the real problem, and perhaps the only problem -
all this RFC does, is provide a stop-gap solution. What we should really be
talking about, is implementing the RFC that addresses the existing gap in
the the existing feature of the language.
Your arguments don't make sense to me. It's somehow easier to choose
between two different characters * and ? versus electing to call a function
or not? I don't see how - it still requires an active choice, and I don't
believe there's any (sound) way around that.
All this RFC changes is the syntax - not the problem.
Addition of a feature like this will affect even those who don't use it -
we all collaborate in teams, and most of us contribute to open source
projects... a feature like this will bring global state, side-effects and
many other interesting problems even to those who don't elect to use it,
when they inherit or consume code that does.
The poll doesn't make a whole lot of sense either, because you're asking
specifically about the proposed feature, rather than asking in general
about the problem. This doesn't prompt people to think about the problem -
it prompts them to consider the proposed solution. It's easy enough to look
at this on the surface and think "sure, that solves it" - reasoning about
the impact on the language, or deeper problems not directly relating to
this on the surface, requires more of an involvement than just a quick
click on a radio button.
> More than 90% of output data - is data from DB and must be HTML-encoded
Yet, you argue we need a function registry for all kinds of other escape
operations to address the other 10%. I can't follow this line of thinking.
If the 90% use case is HTML escaping (with UTF-8 encoding, as is likely
true) then maybe I could accept the addition of syntax just for that.
*Maybe*.
I would still be *much* more concerned about the limited usefulness of
functions in general, which could be more generally addressed by solving
autoloading.
I view this RFC as a huge distraction and, if implemented, addressing that
one use-case for functions (templates) we're more likely to put off the
deeper issues for even longer.
Please, let's focus on improving the language in general - rather than
improving one isolated use-case.
On Sat, Jul 16, 2016 at 5:33 PM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> Hello.
> I have created RFC about context-dependent escaping operator.
> https://wiki.php.net/rfc/escaping_operator
>
> Initial discussion was here: http://marc.info/?t=146619199100001
>
>
> At first, I wanted to add a call of special function like
> escaper_call($str, $context), which performs html-escaping by default and
> can be replaced with a separate extension for extended work with contexts.
> But then I figured out better variant.
>
>
> Main idea.
>
> Operator has the following form:
>
> <?* $str ?>
> <?* $str, 'html' ?>
> <?* $str, 'js | html' ?>
>
> Both expressions can be any type which can be converted to string. Second
> expression is optional.
>
> I changed '~' sign because it is not present on keyboard layouts for some
> european languages. And also it does not give any error on previous
> versions of PHP with short tags enabled, because this is recognized as
> bitwise operation.
>
>
> Operator is compiled into the following AST:
>
> echo PHPEscaper::escape(first_argument, second_argument);
>
> Don't you forget that we already have special operator for one function?
> Backticks and shell_exec(). New operator is compiled very similar to it.
>
>
> There is a default implementation of the class 'PHPEscaper'. It has 4
> static methods:
>
> PHPEscaper::escape($string, $context = 'html');
> PHPEscaper::registerHandler($context, $escaper_function);
> PHPEscaper::unregisterHandler($context);
> PHPEscaper::getHandlers();
>
> Method PHPEscaper::escape($string, $context) splits $context by '|'
> delimiter, all parts are trimmed, and then calls registered handler for
> every context in a chain.
> 'html' is default value for context, and it has special handling.
> If there is no handler for 'html' context, it calls
> htmlspecialchars($string, ENT_QUOTES | ENT_SUBSTITUTE);
>
>
> We can use it like this:
>
> <?php
> // anywhere in application
> PHPEscaper::registerHandler('html', [MyEscaper, 'escapeHtml']);
> PHPEscaper::registerHandler('js', function($str) { return
> json_encode($str); });
> ?>
> <?* $str, 'js | html' ?>
>
>
> And even more.
> In the AST, 'PHPEscaper' is registered as not fully qualified name
> (ZEND_NAME_NOT_FQ).
> This allows us to use namespaces and autoloading:
>
> <?php use MyEscaper as PHPEscaper; ?>
> <?* $str, 'js | html' ?>
>
> MyEscaper::escape($str, 'js | html') will be called.
>
>
> In this way we can have autoloading, multiple contexts, HTML escaping by
> default, and full control and customization.
> This is not an operator for one function, just there is one default
> implementation.
>
> My first goal is to draw the attention on the problem with a security and
> HTML escaping. Exact implementation is secondary thing.
>
> This small change can really improve a security and make development easier
> in many applications.
>
>
> How do you think, maybe also it would be good to create some official poll
> about this feature and to know community opinion about it?
>
