Hey Zeev. I'm not that deep into @internals and might not get the subtle subtext. English is not my native tongue so I might phrase things in a way that doesn't transport the whole meaning of my thoughts. But your Mail really left me curious:
On Thu, 12 Sep 2019 at 10:44, Zeev Suraski <z...@php.net> wrote:
> I was really really hoping that we will avert having to dive into this and
> instead go for the alternative solution that was proposed of changing
> default php.ini error levels. But since the RFC went on to a vote - we
> need
> to make something clear.
>
>
>
> The RFC process was never, ever meant to handle fundamental changes to the
> language. It was meant to deal predominantly with additions to the
> language, as can be inferred from numerous parts in the phrasing. As I
> mentioned in the past - it wasn't even intended to deal with simpler
> deprecations, but it appears that the cat is out of the bag on this one.
> However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
> of the same bag. Using the RFC to deprecate fundamental behaviors of the
> language - such as how the language deals with undefined variables - is
> simply off the table.
Given the fact that you have the authority to say so, what actually *is*
the process then to make "fundamental changes to the language"?
>
>
>
> You may be wondering, in that case, what processes do we have to deal with
> such changes then? The answer is simple. We don't. We don't have to have
> them either - the fundamental language behaviors are here to stay.
But we still need processes to define which are the "fundamental
language behaviours". And as change is the only constant in
software-development, these "fundamental language behaviours" might, can
and probably should be changeable. I'm not saying they need to change,
but it has to be possible to change them. Otherwise we would still
program business-logic in C as that was Rasmus' fundamental idea IIRC
(Correct me if I'm wrong)
>
> Deprecating the ability to rely on the expected default value of
> uninitialized variables falls squarely in that category.
>
>
>
> Reclassifying a notice to a warning is a possibility - people's code will
> still run, and they'll be able to continue using these behaviors going
> forward as well if they want to (perhaps with minor tweaks to error
> reporting levels). Turning a notice to an error isn't reclassifying an
> error level. It's deprecating a behavior - and we're not talking about
> some
> esoteric extension, but a documented, well-defined, fundamental behavior of
> the language for over two decades. The fact many of you think it's
> horrible
> does not change that. Deprecating such fundamentals is simply outside of
> the mandate of internals@, regardless of whatever majority appears to
> exist
> in favor of it at a given time.
>
>
>
> Similarly - adding typed variables - is certainly a future option.
> Changing
> PHP to require typed variables (without opting in) - is well outside of the
> internals@ mandate.
So tell us, what is *insight* the @internals mandate. And who has the
mandate to change the things @internals does not have the mandate to.
From what i see you tell us (@internals) "You're not allowed to do so,
but I will not tell you who *is* allowed." So for me that raises two
main questions:
1. Who then has the mandate to do so?
2. By what authority are you making this statement?
I'm looking forward to your answers.
Cheers
Andreas
>
>
>
> For areas like that - our options are either doing nothing, or providing
> opt-in mechanisms to cater to stricter-loving audiences. I'm all for the
> 2nd option, but there is no 3rd.
>
>
>
> Zeev
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
signature.asc
Description: OpenPGP digital signature
