The idea is good, but I think that is not pratical in general.
---
First point: we should define each new identifier that could be used.
It not make clear what this identifier does or even how it should
works when a package redefines what it does.
For instance:
// file1.php
set_escape_handler('e', 'html_entities_encode');
// file2.php
set_escape_handler('e', 'my_own_encode');
// file3.php
<?* $value, 'e' ?>
If file1.php includes file3.php, it should use first implementation.
If file2.php does that, so will run the second implementation. I can't
control from it come.
If file1.php includes file2.php, what should happen? error? override?
You can solve that by using the namespace, but then the implementation
should be something like:
<?* $value, \Namespace::e ?>
But if you do that, is better you call it directly.
---
Second point: can create a confusion with echo syntax, because it
accepts comma separated arguments, like in <?php echo 1, 2, 3; ?>
---
Third point: the second argument is a string separated by comma,
instead of separate each argument by it self.
It is a string too, instead of an identifier like in <?* $value, escape ?>
---
Fourth point: this will create conflict to IDE, as joined string (<?*
$value, 'escape, json' ?>) is hard to identify each argument item, as
splitted string (<?* $value, 'escape', 'json' ?>) can confuse with a
user string (if you get), as identifier is better, but it can conflict
with const, but even if we ignore that, IDE will have problem by
identify where you have defined it. Let's suppose that you have
defined by a generic function, like:
function create_escape($escape, $callback) {
set_escape_handler($escape, function () use ($callback) { return
doSomethingWith($callback) });
}
create_scape('e', 'my_own_encode');
---
Fifth point: you can't use arguments on each escape to change the mean
of what happen, so I need define each possibility (that could be a
lot). For instance: imagine that I have a escape that does, on
reality, a "clamp" that do a $value bet more than min, and less than
max. It should receives two arguments (min and max) and optional one
(inclusive). Currently I could do it like: <?= echo clamp($value, 5,
25, true); ?>. How you can do that on your case?
---
Sixth point: current escape methods seems be more eficient and without
create a new operator, like: <?php e($value); ?>
But it can be improved with Sara suggestion with the pipe v2 (chain?)
operator like <?php $value~>e($$); ?>
---
As conclusion, I think that if PHP create something like that, so is
better PHP implements their own template engine system, turning this
operation faster. But it can inflate PHP code with a template option
that you don't like to use (for instance, I like Blade, but you can
like Twig, another like PHP native template engine).
I think that to some os problems above is create a exclusive scope to
you apply your 'escapers', for instance:
$escape = new SplEscaper;
$escape->support('e', function () { ... });
$escape->require('myfile.php');
In this case, it'll require myfile.php and accept your escapers based
on this instance.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
