>If you want to go further, dropping the PHP tag altogether would be nice,
since it would prevent context switching between PHP/HTML/JS/whatever.
>That would force Wordpress to update their whole
code base. >:{)>
I wholeheartedly support this initiative but I do not see it going through
without a
The problem I see with this approach is that a keyword for skipping
parameters
would really just be a stopgap solution until something like Named
Parameters
can be added.
Is it really appropriate to add a feature that only serves a temporary
purpose?
On Sat, Apr 6, 2019 at 5:15 PM Craig Duncan
>In order to use named parameters, somebody needs to have declared what
those names are, and made them a stable API. If they're automatically
supported on existing functions, the author might not intend them to be
used, or even realise they can, so not keep them stable (I tend to think of
> While I realize my email is unpleasant for many to read, it's in the
context of an RFC that attempts to do something that is strictly
inappropriate and out of the question. Stating the fact, that the RFC
process was never meant to allow this to be done, is a statement of fact.
[...]
> There
> I have already told you that the output of this function was never meant
> for human consumption.
> It was originally added to aid in caching of larger complicated data
> structure through the likes of apc's opcode cache.
It is sometimes used for human consumption now, though. For example,
my
I'm not 100% certain but I believe what chopins is proposing is the ability
to require()/include() files generated by opcache, without including the
.php file.
The reference to __FILE__ is I believe a warning to using relative paths,
since the compiled opcode file would be in a different
