On Sat, Jul 26, 2014 at 3:16 PM, Zeev Suraski <z...@zend.com> wrote:
> Kris,
>
>
>
> I’ll make it short.
>
>
>
> EVERY RFC affects the language in *some* way – be it its features,
> positioning, perception, performance, implementation, testability, you name
> it.
>
I believe that argument is specious. The RFC says, "....a feature
affecting the language *itself*" (emphasis mine). A feature that affects
performance need not necessarily affect the language itself. For example,
an RFC to add an APXS configuration option to the configure script would
have no impact on the language itself, even though it technically involves
a modified implementation and testing scenario. And affecting people's
"perception" of PHP most certainly does not constitute a feature that
affects the language itself, unless you're making a quantum theory argument
wherein the mere act of observing something alters its state.
Finally, here's an example from your RFC of how it *directly* impacts the
language itself:
> PHPNG doesn't keep original values of arguments passed to user functions,
so func_get_arg() and func_get_args() will return current value of argument
instead of the actually passed. The following code is going to be affected
“function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”
>
> Function parameters with duplicate name are not allowed anymore.
Definitions like “function foo($x,$x) {}” will lead to compile time error
“Redefinition of parameter”
So even IF you want to reduce the scope of the 2/3 requirement to language
impacts in userland only, your RFC *still* falls under that requirement
because it directly affects the language itself in userland, as described
above. I would again invite you to reconsider your position on this and
avoid a protracted fight on this that would only serve to split the
community.
--Kris
