> How will a new output operator help in this case?
> You still have to search for `<?=`, `<? echo`, `<? print` occurrences and
replace them with `<?~`.
> Saying that one can forget to add `<?= h()` can be applied to `<?~` as
well,
> you can miss `<? echo` somewhere in a template and get the same result at
the end
No. <?= (int)$some_id ?>, <? echo htmlspecialchars() ?> and others usually
are safe in current code.
But we need to write new code for new functionality in a project.
Let's say we've added new column in database, and added output of it in our
template.
It is very easy to write <div><?= $obj->new_text_column ?></div> for
testing purposes and then leave it as is.
The problem is that <?= h($something) ?> and <?= $something ?> both work
good, one is a subset of another. But the second variant is unsafe. We can
forget to write that main part.
But we cannot forget to write '=' in '<?=' or '~' in '<?~', because it will
not work. It just will not output anything and we can notice this.
Also we need to select what to write, they are mutualy exclusive. And we
have to write <?~ ?> almost everywhere, <?= ?> is needed only sometimes.
> It would be much more productive to get the RFC written and to provide
suggestions on improvements
Thanks. My wiki account is 'michael-vostrikov'.
2016-07-01 16:46 GMT+05:00 Davey Shafik <da...@php.net>:
> All,
>
> Anybody can write an RFC and call a vote whenever they want within the
> guidelines set forth for RFCs.
>
> It would be much more productive to get the RFC written and to provide
> suggestions on improvements (e.g. syntax choice, default options, ways to
> customize), rather battling against it. Or stay quite and vote no. Or do
> both.
>
> I am personally against this idea as it stands but maybe there is a middle
> ground and maybe some good can come of it. For example, autoloading
> functions.
>
> As a suggestion:
>
> Perhaps the ability to register a default stream filter for the default
> output buffer paired with file level declarations and/or context tagging
> within blocks is a possible solution. So something like:
>
> declare(strict_types=1; output_filter_args=['label' => [ENT_QUOTES |
> ENT_SUBSTITUTE]]);
>
> // must be constant scalar expression?
> // Would be passed in directly as is, the choice for an array with context
> aware keys/values is up to you
>
> register_output_filter(function($buffer, $label) { }, 'label'); // should
> have similar API to spl autoloading, with multiple callback stack
>
> <?label:="string"; ?>
>
> ----
>
> Something like this would start to solve some of the problems of context,
> default arguments, etc.
>
> I think functions to set the filter options might be better but using
> declare makes it easier to limit to current file scope and ensures
> consistent placement at top. Also I realize I said to use stream filters
> and I've used a closure here. Stream filters are complex due to the whole
> bucket brigade/continuous data stream thing, but have the advantage of
> being much more performant and resource friendly. Maybe allow both types?
> Simple callbacks for ease of use, stream filters for performance and
> complex stuffs.
>
> TL;DR: what's your account? Let's give RFC karma and vote it down if you
> don't want it.
>
>
> - Davey
>
>
