Everything

php

Home » Project » Newsgroups » php.internals » Changing fundamental language behaviors »

Changing fundamental language behaviors

php.internals

Zeev Suraski

6 years ago

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.



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.

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.



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

Dan Ackroyd

6 years ago

On Thu, 12 Sep 2019 at 15:44, Zeev Suraski <zeev@php.net> wrote:

>
> The RFC process was never, ever meant to handle fundamental changes to the
> language.

The only appropriate response to this is "lolwat?".

You keep making up rules...that don't exist. You can't expect people
to suddenly stop using RFCs to change the language just because you
say so.

Please stop this behaviour. It's really not appropriate.

sincerely
Dan
Ack

Arvids Godjuks

6 years ago

чт, 12 сент. 2019 г. в 16:53, Dan Ackroyd <Danack@basereality.com>:

> On Thu, 12 Sep 2019 at 15:44, Zeev Suraski <zeev@php.net> wrote:
> >
> > The RFC process was never, ever meant to handle fundamental changes to
> the
> > language.
>
> The only appropriate response to this is "lolwat?".
>
> You keep making up rules...that don't exist. You can't expect people
> to suddenly stop using RFCs to change the language just because you
> say so.
>
> Please stop this behaviour. It's really not appropriate.
>
> sincerely
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Agree and support,

but I mostly want to convey this to everyone:

For once, let's not knee-jerk post reply.
Let's take a day to stew on this, formulate the though and express it.
I will do the same, cause I really want to knee-jerk here, but we know how
that ended in recent months and issues it caused.

So let's take the opportunity to voice our opinions in an orderly manner
since Zeev basically opened this can of worms and I honestly do not see
this going well.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Olumide Samson

6 years ago

You first me on that reply Dan, I guess I should just say "the naysayers
are back", I can see their footprint all around.

The RFC is Request for Comment on any changes, is there an explicit or
implicit mention about what kind of proposed changes can be made?

Mr/Mrs Zeev are you for PHP or against it?
I know you are one of the authors of Zend Engine, but please follow the
rules and don't make rules simply because something is going the way you
don't want it to.

That's why there's this called "vote".

On Thu, Sep 12, 2019, 3:52 PM Dan Ackroyd <Danack@basereality.com> wrote:

Zeev Suraski

6 years ago

> -----Original Message-----
> From: Olumide Samson <oludonsexy@gmail.com>
> Sent: Thursday, September 12, 2019 6:03 PM
> To: Dan Ackroyd <Danack@basereality.com>
> Cc: Zeev Suraski <zeev@php.net>; PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Changing fundamental language behaviors
>
> The RFC is Request for Comment on any changes, is there an explicit or implicit
> mention about what kind of proposed changes can be made?

While the Voting RFC was probably one of my worst creations - because it's was so laconic and lacking (although it still probably did more good for PHP than bad) - yes - there's a strong implication as to what it's meant to deal with and what it isn't meant to deal with.

Here's what the Voting RFC said:
"Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible"

I understand this isn't written black-on-white that you can't deprecate a fundamental language behavior.  But it's clear that "having to win a 2/3 vote" isn't quite the definition of "irreversible".  The idea behind the 2/3 requirement (a number that I came up with) was to ensure that the motivation to undo that addition/change will likely remain very low in the years following the vote on the RFC.  Why?  Because once it's in - it's in.  It cannot be taken out.  It's irreversible.

So no, a 2/3 vote does not get us the mandate to deprecate a fundamental language behavior.  It's basically a reasonably high bar to add something to the language - given that we know that once we add it, we cannot take it away.  Nothing more, nothing less.

Zeev

Marco Pivetta

6 years ago

Hi Zeev,

On Thu, Sep 12, 2019 at 4:44 PM Zeev Suraski <zeev@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.
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
>

If you want to have an authoritative say on what the RFC process is for or
not, please start a new RFC about it: your mail is just straight out
inappropriate.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Zeev Suraski

6 years ago

> -----Original Message-----
> From: Marco Pivetta <ocramius@gmail.com>
> Sent: Thursday, September 12, 2019 5:59 PM
> To: Zeev Suraski <zeev@php.net>
> Cc: PHP Internals List <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Changing fundamental language behaviors
>
> If you want to have an authoritative say on what the RFC process is for or not,
> please start a new RFC about it: your mail is just straight out inappropriate.

No Marco.  The RFC process wasn't meant to deal with who has authoritative say any more than it was meant to deal with changing fundamental behaviors in PHP.  The fact we got used to putting everything to a vote doesn't mean that it can work for anything and everything.

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.

I *hate* to be in the position to be the one who has to point it out and stick to it.  I know how much fire that's going to draw and I know I'd hate every second of it.  But it is what it is.

There are no processes to make fundamental non-opt-in language changes in PHP.  There won't be such processes either.  These behaviors are here to stay.  We can tweak them, we can augment them - we do not get to deprecate or radically change them.

We can (and I believe should) augment them with alternative, stricter opt-in behaviors.  But those who dream of simply changing PHP into a stricter language step by step should understand that this is simply not going to be happen.  Not now, not ever.

Zeev

Morgan Breden

6 years ago

> 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 won't be such processes either.  These behaviors are here to stay.

We can tweak them, we can augment them - we do not get to deprecate or
radically change them.

[...]

> But those who dream of simply changing PHP into a stricter language step

by step should understand that this is simply not going to be happen.  Not
now, not ever.

Zeev, "strictly inappropriate and out of the question" seems like a
statement of opinion to me. While I personally agree with your standpoint
on changing this fundamental behavior, your response here seems out of left
field.

Furthermore, statements like "we do not get to deprecate or radically
change them" and  "this is simply not going to happen" are a wholly
inappropriate response to *any* effort. I respect your vast contributions
to the language and your (usually) level-headed stances on this mailing
list, but you are not the grand czar of PHP and I don't believe that hard
line is yours to make. Declaring such a thing reads to me like a spit in
the face of everyone who contributes to the language and to the concept of
a community-driven open source project to begin with.

Over the past few years the movement to push PHP into more modern concepts
has explosively grown in popularity and your resistance to the more rapid
and drastic portions of it is understandable, if nothing else. However,
using your bully pulpit to insist that things you don't like can't be done
leaves a very sour taste in my mouth.

If such limits exist, they should be clear and codified - not something
that exists in the mind of you and whoever else only to be brought up when
someone wants to breach them.

On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski <zeev@php.net> wrote:

Scott Arciszewski

6 years ago

I'd like to weigh in as a voice of reason here.

> There are no processes to make fundamental non-opt-in language changes in PHP.

This part might be reasonable.

> There won't be such processes either. These behaviors are here to stay. We can tweak them, we can augment them - we do not get to deprecate or radically change them.

This part is totally unreasonable.

Let me explain:

"We lack a process" opens a door. If the RFC process is inadequate to
address necessary deprecations and removals, then what process *would*
be adequate and appropriate?

THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe
contrary to Zeev about whether the RFC process is adequate and
appropriate.

"There won't be such processes either" shuts the just-opened door in
the rudest manner possible. This doesn't lead to a productive
conversation, this just ends it with Zeev's opinion being final.

My thoughts:

I think we should give Zeev precisely half of what he wants here:
Let's discuss whether a separate process should be created for
deprecations/removals... and if so, what it would look like. And then
if we come up with something new, in true Internals fashion, create an
RFC and vote on our new addition to the RFC process. (Even Zeev has to
acknowledge that additions are fine, with 2/3 majority.)

But we shouldn't accept his door-shutting terms just because he says so.

Respectfully,

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises


On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski <zeev@php.net> wrote:

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski <scott@paragonie.com>
wrote:

> I'd like to weigh in as a voice of reason here.
>
> > There are no processes to make fundamental non-opt-in language changes
> in PHP.
>
> This part might be reasonable.
>
> > There won't be such processes either. These behaviors are here to stay.
> We can tweak them, we can augment them - we do not get to deprecate or
> radically change them.
>
> This part is totally unreasonable.
>
> Let me explain:
>
> "We lack a process" opens a door. If the RFC process is inadequate to
> address necessary deprecations and removals, then what process *would*
> be adequate and appropriate?
>
> THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe
> contrary to Zeev about whether the RFC process is adequate and
> appropriate.
>
> "There won't be such processes either" shuts the just-opened door in
> the rudest manner possible. This doesn't lead to a productive
> conversation, this just ends it with Zeev's opinion being final.
>
> My thoughts:
>
> I think we should give Zeev precisely half of what he wants here:
> Let's discuss whether a separate process should be created for
> deprecations/removals... and if so, what it would look like. And then
> if we come up with something new, in true Internals fashion, create an
> RFC and vote on our new addition to the RFC process. (Even Zeev has to
> acknowledge that additions are fine, with 2/3 majority.)
>
>

Don't use the term "deprecations and removals" - it's not the right term
here. There are many deprecations and removals that don't fundamentally
change the language. For example, deprecating create_function() after
closure support was added didn't fundamentally change the language.

> But we shouldn't accept his door-shutting terms just because he says so.
>
> Respectfully,
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises
>
>
> On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski <zeev@php.net> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Marco Pivetta <ocramius@gmail.com>
> > > Sent: Thursday, September 12, 2019 5:59 PM
> > > To: Zeev Suraski <zeev@php.net>
> > > Cc: PHP Internals List <internals@lists.php.net>
> > > Subject: Re: [PHP-DEV] Changing fundamental language behaviors
> > >
> > > If you want to have an authoritative say on what the RFC process is
> for or not,
> > > please start a new RFC about it: your mail is just straight out
> inappropriate.
> >
> > No Marco.  The RFC process wasn't meant to deal with who has
> authoritative say any more than it was meant to deal with changing
> fundamental behaviors in PHP.  The fact we got used to putting everything
> to a vote doesn't mean that it can work for anything and everything.
> >
> > 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.
> >
> > I *hate* to be in the position to be the one who has to point it out and
> stick to it.  I know how much fire that's going to draw and I know I'd hate
> every second of it.  But it is what it is.
> >
> > There are no processes to make fundamental non-opt-in language changes
> in PHP.  There won't be such processes either.  These behaviors are here to
> stay.  We can tweak them, we can augment them - we do not get to deprecate
> or radically change them.
> >
> > We can (and I believe should) augment them with alternative, stricter
> opt-in behaviors.  But those who dream of simply changing PHP into a
> stricter language step by step should understand that this is simply not
> going to be happen.  Not now, not ever.
> >
> > Zeev
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Chase Peeler
chasepeeler@gmail.com

Scott Arciszewski

6 years ago

Apologies for my semantic imprecision. I hope the intent of my email
remains clear.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

On Thu, Sep 12, 2019 at 12:56 PM Chase Peeler <chasepeeler@gmail.com> wrote:

Matthew Brown

6 years ago

>
> that don't fundamentally change the language

There's clearly a big disagreement about whether this is a fundamental
change or not.

Preventing something that the entire field of software engineering frowns
upon (and that most PHP developers avoid like the plague) doesn't seem like
a *fundamental* change.

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> that don't fundamentally change the language
>
>
> There's clearly a big disagreement about whether this is a fundamental
> change or not.
>
> Preventing something that the entire field of software engineering frowns
> upon (and that most PHP developers avoid like the plague) doesn't seem like
> a *fundamental* change.
>
>

I would argue that this is exactly such a change. The flexibility of PHP
has often been touted as a feature and something that sets it apart.
Whether that's good or bad is, frankly, irrelevant. There are valid reasons
for not always initializing variables or array keys. It might be a bad
reason in your opinion, but others view it as perfectly acceptable. For 20
years people have developed code based on that feature. It was never
considered an error, and often not even considered bad practice. To
suddenly define it as such is the exact definition of a fundamental change
to the language itself.

What if Java suddenly said that all properties are suddenly private, and
can only be accessed through getter/setter methods? The fact that you
should make properties private and use such methods is a practice that was
drilled into me from day one. Would that justify making such a change,
though?

--
Chase Peeler
chasepeeler@gmail.com

Matthew Brown

6 years ago

>
> What if Java suddenly said that all properties are suddenly private, and
> can only be accessed through getter/setter methods?
>

If Java announced that the next major version was to make the change after
95% of userland developers favoured it and over 2/3rds of their internals
team did, I'd think "huh ok I guess they have good reasons".

For 20 years people have developed code based on that feature. It was never

> considered an error, and often not even considered bad practice

You seem to be arguing against *ever* changing something that a majority
once thought was good, and fundamental to a given system. Lots of things
fall into that category - restricting voting to men, segregation, etc.

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> What if Java suddenly said that all properties are suddenly private, and
>> can only be accessed through getter/setter methods?
>>
>
> If Java announced that the next major version was to make the change after
> 95% of userland developers favoured it and over 2/3rds of their internals
> team did, I'd think "huh ok I guess they have good reasons".
>
> For 20 years people have developed code based on that feature. It was
>> never considered an error, and often not even considered bad practice
>
>
> You seem to be arguing against *ever* changing something that a majority
> once thought was good, and fundamental to a given system. Lots of things
> fall into that category - restricting voting to men, segregation, etc.
>

Now you're just being silly. I actually don't have a problem with
fundamental language change, provided that the positives that are gained
far outweigh the negatives of the BC break and there is no other way to
accomplish those positives without such a BC break.

There are a myriad of ways to achieve what the RFC attempts to achieve.
Whether that's analysis tools, custom error handlers, detailed code
reviews, etc. Nothing prevents anyone from initializing all of their
variables or performing as many sanity checks on a variable before
accessing it as they want to. Nothing in the RFC is required to implement
other new functionality like enums, union types, variable typing, etc.

I also think it's a bit of a stretch to compare something like variable
initialization with things that denied people their basic human rights.

--
Chase Peeler
chasepeeler@gmail.com

Stephen Reay

6 years ago

> On 13 Sep 2019, at 00:41, Chase Peeler <chasepeeler@gmail.com> wrote:
>
> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com>
> wrote:
>
>> What if Java suddenly said that all properties are suddenly private, and
>>> can only be accessed through getter/setter methods?
>>>
>>
>> If Java announced that the next major version was to make the change after
>> 95% of userland developers favoured it and over 2/3rds of their internals
>> team did, I'd think "huh ok I guess they have good reasons".
>>
>> For 20 years people have developed code based on that feature. It was
>>> never considered an error, and often not even considered bad practice
>>
>>
>> You seem to be arguing against *ever* changing something that a majority
>> once thought was good, and fundamental to a given system. Lots of things
>> fall into that category - restricting voting to men, segregation, etc.
>>
>
> Now you're just being silly. I actually don't have a problem with
> fundamental language change, provided that the positives that are gained
> far outweigh the negatives of the BC break and there is no other way to
> accomplish those positives without such a BC break.
>
> There are a myriad of ways to achieve what the RFC attempts to achieve.
> Whether that's analysis tools, custom error handlers, detailed code
> reviews, etc. Nothing prevents anyone from initializing all of their
> variables or performing as many sanity checks on a variable before
> accessing it as they want to. Nothing in the RFC is required to implement
> other new functionality like enums, union types, variable typing, etc.
>
> I also think it's a bit of a stretch to compare something like variable
> initialization with things that denied people their basic human rights.
>
> --
> Chase Peeler
> chasepeeler@gmail.com

Please, will someone arguing against making use of undefined variables a higher severity, explain to me why the same argument was not made for use of undefined constants, for which the RFC to deprecate/remove support, passed 41:0.

How is one undefined symbol more acceptable than another undefined symbol?

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> What if Java suddenly said that all properties are suddenly private, and
>> can only be accessed through getter/setter methods?
>>
>
> If Java announced that the next major version was to make the change after
> 95% of userland developers favoured it and over 2/3rds of their internals
> team did, I'd think "huh ok I guess they have good reasons".
>
>

I call shenanigans on that 95% number. Can you please back that up?
Personally, I don't think it's even possible to gauge userland
support because the vast majority of userland developers aren't involved in
the community at all. Those people don't even know this is being discussed,
and probably won't until they start looking to upgrade to PHP 8.

> For 20 years people have developed code based on that feature. It was
>> never considered an error, and often not even considered bad practice
>
>
> You seem to be arguing against *ever* changing something that a majority
> once thought was good, and fundamental to a given system. Lots of things
> fall into that category - restricting voting to men, segregation, etc.
>
>>

--
Chase Peeler
chasepeeler@gmail.com

Olumide Samson

6 years ago

On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown <matthewmatthew@gmail.com>
> wrote:
>
> > What if Java suddenly said that all properties are suddenly private, and
> >> can only be accessed through getter/setter methods?
> >>
> >
> > If Java announced that the next major version was to make the change
> after
> > 95% of userland developers favoured it and over 2/3rds of their internals
> > team did, I'd think "huh ok I guess they have good reasons".
> >
> >
> I call shenanigans on that 95% number. Can you please back that up?
> Personally, I don't think it's even possible to gauge userland
> support because the vast majority of userland developers aren't involved in
> the community at all. Those people don't even know this is being discussed,
> and probably won't until they start looking to upgrade to PHP 8.
>
> I'm sure you need to read the message properly before replying, he ain't

talking about PHP there...

Even 95% can be called anything(of users who are involved in the community,
who knows, who are actual users, etc)

Lynn

6 years ago

On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> There are valid reasons for not always initializing variables or array
> keys. It might be a bad
> reason in your opinion, but others view it as perfectly acceptable.
>

I recently had to fix a bug where a variable was renamed, caused a merge
conflict and resulted in months long of changing a business process with a
subtle bug, as null was not the intended initialized value. Whether or not
people should initialize variables is debatable from a programming
perspective. From a reader's perspective it's really important to have
variables initialized with a default value, even if it's just null, to
prevent missing certain assignment branches and avoid bugs. From my
perspective, this should've thrown an error, so we would've fixed it the
same day. Now PHP simply broke our business process for months.

Yes, we hide notices, even in production as our logging server would die
within a minute if we'd turn it on. Yes, this is a massive legacy code base
where lots of tests are lacking. Can we change this? Sure, will take years
though. Would we have benefited from PHP throwing an error in this case?
Most certainly, would've saved us a lot of headache, and money.

You argue that it's a fundamental language change, I -and seemingly a lot
of others- argue that this is more of a bug fix.

Regards,
Lynn van der Berg

Mike Schinkel

6 years ago

> On Sep 12, 2019, at 10:37 AM, Lynn <kjarli@gmail.com> wrote:
>
> On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler <chasepeeler@gmail.com> wrote:
>
>> There are valid reasons for not always initializing variables or array
>> keys. It might be a bad
>> reason in your opinion, but others view it as perfectly acceptable.
>>
>
> I recently had to fix a bug where a variable was renamed, caused a merge
> conflict and resulted in months long of changing a business process with a
> subtle bug, as null was not the intended initialized value. Whether or not
> people should initialize variables is debatable from a programming
> perspective. From a reader's perspective it's really important to have
> variables initialized with a default value, even if it's just null, to
> prevent missing certain assignment branches and avoid bugs. From my
> perspective, this should've thrown an error, so we would've fixed it the
> same day. Now PHP simply broke our business process for months.
>
> Yes, we hide notices, even in production as our logging server would die
> within a minute if we'd turn it on. Yes, this is a massive legacy code base
> where lots of tests are lacking. Can we change this? Sure, will take years
> though. Would we have benefited from PHP throwing an error in this case?
> Most certainly, would've saved us a lot of headache, and money.
>
> You argue that it's a fundamental language change, I -and seemingly a lot
> of others- argue that this is more of a bug fix.

Just a few weeks ago I was refactoring some particularly horrible code developed by previously employed developers — a code based that has a 1400 line function and many other functions 100s of lines long, and I added some initialization for variable and array elements prior to their use.

Unfortunately my changes broke the code because the original developer using isset($var) as branching criteria.  After finding this bug, I realized that this code base uses that technique frequently.  I am know from lots of experience that this is a common technical among WordPress plugins.

If PHP8 were to change to require variables and/or array elements to be initialized then this code base and any similar to it will be broken. Companies with these code bases almost certainly will simply not upgrade to PHP 8.  Probably ever.

BTW, prior to gaining this company as a client, the internal people felt that the codebase needed to be completely rewritten rather than incrementally refactored. And because rewriting would have been such a large project they have been putting it off for several years.  In their case, we will be cleaning up the code base (although doing so will be very costly for them.)

And I estimate there are a large number of similar scenarios in the wild that do not currently have plans the people or the funds to clean up their similar code.

#jmtcw

-Mike

Olumide Samson

6 years ago

I think it would do this list more good than not, if we talk or assume
about some people who will ever or never upgrade...
Seriously?
How do you know if they would never or ever upgrade, you can only and
should probably speak for yourself...

If they want more customers(translating to revenue), they can upgrade and
if they don't it's all up to them...

On Thu, Sep 12, 2019 at 6:59 PM Mike Schinkel <mike@newclarity.net> wrote:

> > On Sep 12, 2019, at 10:37 AM, Lynn <kjarli@gmail.com> wrote:
> >
> > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler <chasepeeler@gmail.com>
> wrote:
> >
> >> There are valid reasons for not always initializing variables or array
> >> keys. It might be a bad
> >> reason in your opinion, but others view it as perfectly acceptable.
> >>
> >
> > I recently had to fix a bug where a variable was renamed, caused a merge
> > conflict and resulted in months long of changing a business process with
> a
> > subtle bug, as null was not the intended initialized value. Whether or
> not
> > people should initialize variables is debatable from a programming
> > perspective. From a reader's perspective it's really important to have
> > variables initialized with a default value, even if it's just null, to
> > prevent missing certain assignment branches and avoid bugs. From my
> > perspective, this should've thrown an error, so we would've fixed it the
> > same day. Now PHP simply broke our business process for months.
> >
> > Yes, we hide notices, even in production as our logging server would die
> > within a minute if we'd turn it on. Yes, this is a massive legacy code
> base
> > where lots of tests are lacking. Can we change this? Sure, will take
> years
> > though. Would we have benefited from PHP throwing an error in this case?
> > Most certainly, would've saved us a lot of headache, and money.
> >
> > You argue that it's a fundamental language change, I -and seemingly a lot
> > of others- argue that this is more of a bug fix.
>
> Just a few weeks ago I was refactoring some particularly horrible code
> developed by previously employed developers — a code based that has a 1400
> line function and many other functions 100s of lines long, and I added some
> initialization for variable and array elements prior to their use.
>
> Unfortunately my changes broke the code because the original developer
> using isset($var) as branching criteria.  After finding this bug, I
> realized that this code base uses that technique frequently.  I am know
> from lots of experience that this is a common technical among WordPress
> plugins.
>

I think they could switch to using null instead, or perhaps get something
else to differentiate what they have initialized or not, that shouldn't
stop them from using PHP, probably it will only make them not upgrade to
PHP if they think their bad coding practice is the way forward and the best
way to code..

If PHP8 were to change to require variables and/or array elements to be

> initialized then this code base and any similar to it will be broken.
> Companies with these code bases almost certainly will simply not upgrade to
> PHP 8.  Probably ever.
>
> This is merely assumptions and you can't speak for companies you don't

know, what's the statistics backing these your use of "ever and never"?

> BTW, prior to gaining this company as a client, the internal people felt
> that the codebase needed to be completely rewritten rather than
> incrementally refactored. And because rewriting would have been such a
> large project they have been putting it off for several years.  In their
> case, we will be cleaning up the code base (although doing so will be very
> costly for them.)
>
> And I estimate there are a large number of similar scenarios in the wild
> that do not currently have plans the people or the funds to clean up their
> similar code.
>
> It's up to them, PHP 7 is still available and will always be available for

them to use...

Lynn

6 years ago

On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <mike@newclarity.net> wrote:

>
>
> Just a few weeks ago I was refactoring some particularly horrible code
> developed by previously employed developers — a code based that has a 1400
> line function and many other functions 100s of lines long, and I added some
> initialization for variable and array elements prior to their use.
>
> Unfortunately my changes broke the code because the original developer
> using isset($var) as branching criteria.  After finding this bug, I
> realized that this code base uses that technique frequently.  I am know
> from lots of experience that this is a common technical among WordPress
> plugins.
>
>

The bug is not that you initialized the variable, it's that you initialized
it with a different value: https://3v4l.org/8mB8B
```
var_dump(isset($a));
$a = null;
var_dump(isset($a));

// gives
bool(false)
bool(false)
```

Whenever one of these errors will occur, you can initialize either the
array key or variable with null and it will work again without changing
behavior. If anything, Wordpress shouldn't be an argument to not improve
PHP, though I think it's important to consider the impact of a change,
including for the Wordpress community. However, I think most people agree
that the quality of Wordpress code and Plugins is highly debatable. I don't
like the idea of not being able to progress because Wordpress users won't
upgrade PHP.

Regards,
Lynn van der Berg

Olumide Samson

6 years ago

On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown <matthewmatthew@gmail.com>
> wrote:
>
> > that don't fundamentally change the language
> >
> >
> > There's clearly a big disagreement about whether this is a fundamental
> > change or not.
> >
> > Preventing something that the entire field of software engineering frowns
> > upon (and that most PHP developers avoid like the plague) doesn't seem
> like
> > a *fundamental* change.
> >
> >
> I would argue that this is exactly such a change. The flexibility of PHP
> has often been touted as a feature and something that sets it apart.
> Whether that's good or bad is, frankly, irrelevant. There are valid reasons
> for not always initializing variables or array keys.

The major valid reason i see is creating a bolierplate or being lazy to
initialize the variable with even null or similar null-type depending on
its context.

It might be a bad reason in your opinion, but others view it as perfectly

> acceptable.

Who are those "others"?
I think he(me included) is also one of those "others" that view it as bad
programming style...

For 20 years people have developed code based on that feature. It was never

> considered an error, and often not even considered bad practice.

It was considered an error, that's why you were been warned or given
notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of
already-problematic-file.php" and only if we want to remove Notice,Warning
or Error in the language.

> To suddenly define it as such is the exact definition of a fundamental
> change
> to the language itself.
>

Fundamental is always "fundamental", i think there's no good definition for
it in this context, so leave fundamental changes out of this discussion as
something totally bad been cleaned up is a fundamental change and something
new but not used right and changed to be used right is also fundamental...

>
> What if Java suddenly said that all properties are suddenly private, and
> can only be accessed through getter/setter methods? The fact that you
> should make properties private and use such methods is a practice that was
> drilled into me from day one. Would that justify making such a change,
> though?
>
> I'm not sure how this relates, i think Java would let you see the good or

bad, it's up to you to see or not from their view, let the majority move
forward and don't be a stopping stone in moving this language past the 1993
bondage(needle-haystack, inconsistent naming and many issues we couldn't
count)...

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 1:39 PM Olumide Samson <oludonsexy@gmail.com> wrote:

>
>
> On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler <chasepeeler@gmail.com>
> wrote:
>
>> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown <matthewmatthew@gmail.com>
>> wrote:
>>
>> > that don't fundamentally change the language
>> >
>> >
>> > There's clearly a big disagreement about whether this is a fundamental
>> > change or not.
>> >
>> > Preventing something that the entire field of software engineering
>> frowns
>> > upon (and that most PHP developers avoid like the plague) doesn't seem
>> like
>> > a *fundamental* change.
>> >
>> >
>> I would argue that this is exactly such a change. The flexibility of PHP
>> has often been touted as a feature and something that sets it apart.
>> Whether that's good or bad is, frankly, irrelevant. There are valid
>> reasons
>> for not always initializing variables or array keys.
>
>  The major valid reason i see is creating a bolierplate or being lazy to
> initialize the variable with even null or similar null-type depending on
> its context.
>
> It might be a bad reason in your opinion, but others view it as perfectly
>> acceptable.
>
>  Who are those "others"?
> I think he(me included) is also one of those "others" that view it as bad
> programming style...
>
> For 20 years people have developed code based on that feature. It was never
>> considered an error, and often not even considered bad practice.
>
>  It was considered an error, that's why you were been warned or given
> notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of
> already-problematic-file.php" and only if we want to remove Notice,Warning
> or Error in the language.
>

No, as discussed previously, notices were never meant to signify a definite
issue. They are "Hey, this might be an issue, it might not, maybe check it
out if you want?" thing. This RFC is proposing that we actually halt
execution of programs that currently work perfectly fine and run exactly as
they were intended to.

> To suddenly define it as such is the exact definition of a fundamental
>> change
>> to the language itself.
>>
> Fundamental is always "fundamental", i think there's no good definition
> for it in this context, so leave fundamental changes out of this discussion
> as something totally bad been cleaned up is a fundamental change and
> something new but not used right and changed to be used right is also
> fundamental...
>

I would said fundamental is any behavior that is expected and intended. At
this point, the fact that you don't have to initialize your variables is an
intended feature of the language. That means people should be able to
depend on such a feature existing. The fact that you don't like it
shouldn't be a justification for breaking that, especially when nothing is
stopping you from being as strict as you want with your own code. You can
also hold any third party libraries that you use to the same standard if
you want.

>
>> What if Java suddenly said that all properties are suddenly private, and
>> can only be accessed through getter/setter methods? The fact that you
>> should make properties private and use such methods is a practice that was
>> drilled into me from day one. Would that justify making such a change,
>> though?
>>
>> I'm not sure how this relates, i think Java would let you see the good or
> bad, it's up to you to see or not from their view, let the majority move
> forward and don't be a stopping stone in moving this language past the 1993
> bondage(needle-haystack, inconsistent naming and many issues we couldn't
> count)...
>

It relates because right now, it's a feature of Java that you can make
properties public and then modify those directly from outside the class.
Since it's an intended feature, a lot of people have written code that
directly accesses public properties.You could argue the only use-case for
doing so is that they are too lazy to write the getter/setter methods, but
that doesn't change the fact that such code exists and is not an error or
even a misuse of a current feature.

--
Chase Peeler
chasepeeler@gmail.com

Jordi Boggiano

6 years ago

On 12/09/2019 16:44, Zeev Suraski wrote:

> 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.
>
>
>
> 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.

While I am not sure your tone will be well received by your target
audience, I just wanted to say I tend to agree.

Breaking BC here does not seem to bring much. If there are cases where
enforcing strictness might allow better JIT for example, then I could
see the case being made. But simply turning working code into fatally
failing code isn't progress.

I know I have a bunch of old stuff running which tends to litter the
error logs with notices, and I don't have time to go fix them so I
ignore because it's fine and it works.

For new projects, what I do, and what I am pretty sure 99% of the
"strict camp" does is essentially boiling down to:

    set_error_handler(function () { throw new \RuntimeException(); });

That's our global strictness flag right there. It's been available for
ages. I don't see why we need to take something away from others to make
such an easy workaround a little less needed. Especially as I don't
imagine we will drop the error handlers. I sure will keep mine around to
keep failing warnings etc as hard fatals.

So what do we gain exactly?

Best,
Jordi

--

Jordi Boggiano
@seldaek - https://seld.be

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 11:01 AM Jordi Boggiano <j.boggiano@seld.be> wrote:

> On 12/09/2019 16:44, Zeev Suraski wrote:
> > 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.
> >
> >
> >
> > 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.
>
>
> While I am not sure your tone will be well received by your target
> audience, I just wanted to say I tend to agree.
>
>

My thoughts as well.

> Breaking BC here does not seem to bring much. If there are cases where
> enforcing strictness might allow better JIT for example, then I could
> see the case being made. But simply turning working code into fatally
> failing code isn't progress.
>
>

Yes!

> I know I have a bunch of old stuff running which tends to litter the
> error logs with notices, and I don't have time to go fix them so I
> ignore because it's fine and it works.
>
>

Can't make that argument. Be prepared to be told how easy it should be for
you to fix it, or, how it's technical debt (ignoring the fact that it's not
technical debt currently, since there is nothing wrong with what was
written) and you're just making things worse by not taking care of it.

> For new projects, what I do, and what I am pretty sure 99% of the
> "strict camp" does is essentially boiling down to:
>
>      set_error_handler(function () { throw new \RuntimeException(); });
>
> That's our global strictness flag right there. It's been available for
> ages. I don't see why we need to take something away from others to make
> such an easy workaround a little less needed. Especially as I don't
> imagine we will drop the error handlers. I sure will keep mine around to
> keep failing warnings etc as hard fatals.
>
> So what do we gain exactly?
>
>

That's the argument I've been making all along. There are so many ways to
accomplish what has been proposed without forcing it on those that don't
want it. It's not required in order to add new features to the language. It
doesn't make the language perform better, either. It's also not taking away
something that is definitely a negative feature. It's taking away something
that many view as a positive feature of the language. If there was no way
to achieve the intended results without making the change, I might be more
sympathetic to making it. But there is. Whether it's an error handler like
you mentioned above, stricter code reviews, public shaming for anyone that
doesn't initialize their variables, or any of the myriad of other options.

> Best,
> Jordi
>
> --
>
> Jordi Boggiano
> @seldaek - https://seld.be
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Chase Peeler
chasepeeler@gmail.com

Matthew Brown

6 years ago

Without your contributions in the early 2000s, PHP likely would not enjoy
the popularity it does today.

But I don't think that gives you veto power over the entire process. You
haven't made any significant contributions to the codebase in over a
decade, and yet the language has still gained many more users in that time
frame, with some fairly major backwards-incompatible changes along the way.

I think you have to come to terms with the fact that today you are a single
vote in this process — though you are, of course, free to write your own
RFCs.

Best wishes,

Matt

On Thu, 12 Sep 2019 at 10:44, Zeev Suraski <zeev@php.net> wrote:

Andreas Heigl

6 years ago

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 <zeev@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:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca                                               |
+---------------------------------------------------------------------+

Zeev Suraski

6 years ago

On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote:

>
>
> > 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)
>

You're right.  The thing is this - as I said, the RFC process was designed
to address additions to the language - as is implied in numerous places
(both the part I quoted from the RFC itself, as well as elements in RFC
template as well as the RFC howto).  It was never meant to handle
deprecations - mainly because we simply weren't doing much of that back in
the days where it was introduced.  It was meant to resolve the issue at
hand at the time (and in the years leading up to it) - which is a formal
way to agree on which features make it in and which ones don't.
Now, over the years (and more and more as of late) - it started being used
for deprecations.  But these deprecations have become more and more extreme
recently in terms of their impact.  Of course I do think deprecations
should be allowed, like in any other language.  I do think we need to have
a higher bar for them in general (both in terms of a clear benefits and
required majority - as is implied in the Voting RFC) - but since we've
grown used to using 2/3 for them - and given the pro-deprecation bias of
the current composition of internals@ - I also realize it will be tough to
do.  But when dealing with deprecation proposals that are likely to effect
a very sizable subset of our userbase and codebase, and deal with some of
the most basic building blocks of the language - we simply can't start
using the same process.  We never have in the past (none of the
deprecations we voted on since 2013 comes even remotely close to the level
of impact of the two proposals that have been put forward to a vote in the
recent couple of months, and the more recent one clearly far outdoes the
prior one in terms of impact).

Should we have 'woken up' many years ago when we started using the Voting
RFC for deprecations it wasn't meant to handle?  Probably.  It would have
been much easier to install a new mechanism.  But it doesn't mean we should
repeat the same mistake, now that it begins to be used to deprecate
mainstream language behaviors.

In terms of telling one from the other - right now, I'm afraid it's a bit
like some other things that fall into the category of 'you know it when you
see it'.  I think few can deny that far-reaching effect of changing how
variables behave in a language, whether they think it's a change for the
better or for the worse.  But I think it *may* be possible to formally
define.  These are just random thoughts at this point - but we could have a
set of apps/frameworks that we use as a testing bed to check the level of
impact of a certain proposal.  If that impact is above a certain threshold
- it will be considered fundamental.  Of course, things like WordPress,
Joomla and MediaWiki would have to be a part of that - not just modern
frameworks.  It's still not ideal since it doesn't account for the majority
of PHP code out there which isn't Open Source - but it may be a start.
There may be other ways - such as letting folks run that analysis on their
own code behind the firewall and report results back.

But there's also a simpler solution to this.  This 'can of worms' as Arvids
called it, wouldn't have been opened had we agreed to focus on extending
PHP instead of trying to replace it with something else.  This is what the
RFC process was meant to facilitate.  It still can, but for that, we need
to change the dynamics from a zero-sum game to a goal of a win/win.  Yes, I
realize that I'm sounding like a broken record.  But call me naive - I'm
still hoping that given it obviously can be done from a technical
perspective (in a wide variety of ways too) - we can find the good will to
do it from a human perspective.

Zeev

Peter Kokot

6 years ago

On Thu, 12 Sep 2019 at 20:35, Zeev Suraski <zeev@php.net> wrote:

>
> On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote:
>
> >
> >
> > > 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)
> >
>
> You're right.  The thing is this - as I said, the RFC process was designed
> to address additions to the language - as is implied in numerous places
> (both the part I quoted from the RFC itself, as well as elements in RFC
> template as well as the RFC howto).  It was never meant to handle
> deprecations - mainly because we simply weren't doing much of that back in
> the days where it was introduced.  It was meant to resolve the issue at
> hand at the time (and in the years leading up to it) - which is a formal
> way to agree on which features make it in and which ones don't.
> Now, over the years (and more and more as of late) - it started being used
> for deprecations.  But these deprecations have become more and more extreme
> recently in terms of their impact.  Of course I do think deprecations
> should be allowed, like in any other language.  I do think we need to have
> a higher bar for them in general (both in terms of a clear benefits and
> required majority - as is implied in the Voting RFC) - but since we've
> grown used to using 2/3 for them - and given the pro-deprecation bias of
> the current composition of internals@ - I also realize it will be tough to
> do.  But when dealing with deprecation proposals that are likely to effect
> a very sizable subset of our userbase and codebase, and deal with some of
> the most basic building blocks of the language - we simply can't start
> using the same process.  We never have in the past (none of the
> deprecations we voted on since 2013 comes even remotely close to the level
> of impact of the two proposals that have been put forward to a vote in the
> recent couple of months, and the more recent one clearly far outdoes the
> prior one in terms of impact).
>
> Should we have 'woken up' many years ago when we started using the Voting
> RFC for deprecations it wasn't meant to handle?  Probably.  It would have
> been much easier to install a new mechanism.  But it doesn't mean we should
> repeat the same mistake, now that it begins to be used to deprecate
> mainstream language behaviors.
>
> In terms of telling one from the other - right now, I'm afraid it's a bit
> like some other things that fall into the category of 'you know it when you
> see it'.  I think few can deny that far-reaching effect of changing how
> variables behave in a language, whether they think it's a change for the
> better or for the worse.  But I think it *may* be possible to formally
> define.  These are just random thoughts at this point - but we could have a
> set of apps/frameworks that we use as a testing bed to check the level of
> impact of a certain proposal.  If that impact is above a certain threshold
> - it will be considered fundamental.  Of course, things like WordPress,
> Joomla and MediaWiki would have to be a part of that - not just modern
> frameworks.  It's still not ideal since it doesn't account for the majority
> of PHP code out there which isn't Open Source - but it may be a start.
> There may be other ways - such as letting folks run that analysis on their
> own code behind the firewall and report results back.
>
> But there's also a simpler solution to this.  This 'can of worms' as Arvids
> called it, wouldn't have been opened had we agreed to focus on extending
> PHP instead of trying to replace it with something else.  This is what the
> RFC process was meant to facilitate.  It still can, but for that, we need
> to change the dynamics from a zero-sum game to a goal of a win/win.  Yes, I
> realize that I'm sounding like a broken record.  But call me naive - I'm
> still hoping that given it obviously can be done from a technical
> perspective (in a wide variety of ways too) - we can find the good will to
> do it from a human perspective.
>
> Zeev
>
>
> >

Just a dumb idea, since there clearly is a majority in favor of the
change with these warnings and strictness and all that now... Why not
making something like an LTS PHP 7.x where all the legacy code would
work OK as long as practically possible and 8.x+ would be the future
of what the developers want and not what business wants? One who won't
upgrade due to the BC breaks also won't need the new features anyway
very realistically.

Microsoft, Zend, and Red Hat have been showing that this is actually
possible. How smart this is for the PHP progress is another story, but
for the business it might be good to think about this also I guess:
https://github.com/microsoft/php-src/releases

So, to make some sort of a milestone with some of the versions -
either 8 or 9 or something.

--
Peter Kokot

Michael Babker

6 years ago

On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> wrote:

> Just a dumb idea, since there clearly is a majority in favor of the
> change with these warnings and strictness and all that now... Why not
> making something like an LTS PHP 7.x where all the legacy code would
> work OK as long as practically possible and 8.x+ would be the future
> of what the developers want and not what business wants? One who won't
> upgrade due to the BC breaks also won't need the new features anyway
> very realistically.
>

Please don't tie the notion of LTS with the idea that a new major can break
BC at will or create larger scale breaks because the previous major has
extended support.  Sooner or later that will end up back at the ++ idea and
fragmentation encouraged by the language is a bad idea.

Olumide Samson

6 years ago

On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <michael.babker@gmail.com>
wrote:

> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> wrote:
>
> > Just a dumb idea, since there clearly is a majority in favor of the
> > change with these warnings and strictness and all that now... Why not
> > making something like an LTS PHP 7.x where all the legacy code would
> > work OK as long as practically possible and 8.x+ would be the future
> > of what the developers want and not what business wants? One who won't
> > upgrade due to the BC breaks also won't need the new features anyway
> > very realistically.
> >
>
> Please don't tie the notion of LTS with the idea that a new major can break
> BC at will or create larger scale breaks because the previous major has
> extended support.  Sooner or later that will end up back at the ++ idea and
> fragmentation encouraged by the language is a bad idea.
>

Not sure you are really seeing the goal...

Why is LTS not a good idea?
And, if the majority want this or that, can we just blow everything into
full dictatorship where i can host my fork of PHP doing uncountable
unwanted things i can call it..?

Any which way, i think the majority of us are tired of writing bad codes,
but since the language is allowing it we don't have choices than to spend
some hours or weeks later debugging the wrong or right line we did that
last "big mistake", who knows there might be another line smiling coz i
haven't detected it...

Michael Babker

6 years ago

On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <michael.babker@gmail.com>
> wrote:
>
>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> wrote:
>>
>> > Just a dumb idea, since there clearly is a majority in favor of the
>> > change with these warnings and strictness and all that now... Why not
>> > making something like an LTS PHP 7.x where all the legacy code would
>> > work OK as long as practically possible and 8.x+ would be the future
>> > of what the developers want and not what business wants? One who won't
>> > upgrade due to the BC breaks also won't need the new features anyway
>> > very realistically.
>> >
>>
>> Please don't tie the notion of LTS with the idea that a new major can
>> break
>> BC at will or create larger scale breaks because the previous major has
>> extended support.  Sooner or later that will end up back at the ++ idea
>> and
>> fragmentation encouraged by the language is a bad idea.
>>
>
> Not sure you are really seeing the goal...
>
> Why is LTS not a good idea?
>

I'm not saying LTS is a bad idea.  I'm saying using LTS to justify shipping
larger scale BC breaks, such as the changes suggested in the last couple of
"contentious" RFCs in a major version because "hey, we have a LTS version
you can use that until you're ready to deal with the backlog of BC breaks
created" is a bad idea. For the record, I happen to agree with as these
RFCs would have minimal impact on my day-to-day work, but having also been
in the role of a maintainer of open source libraries and applications I
also grasp why these types of changes can be problematic to the ecosystem
(both end users of those libraries and applications and the maintainers of
them) and wouldn't jump the gun to ship them without careful consideration.

Olumide Samson

6 years ago

On Thu, Sep 12, 2019 at 8:11 PM Michael Babker <michael.babker@gmail.com>
wrote:

> On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com>
> wrote:
>
>> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <michael.babker@gmail.com>
>> wrote:
>>
>>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com>
>>> wrote:
>>>
>>> > Just a dumb idea, since there clearly is a majority in favor of the
>>> > change with these warnings and strictness and all that now... Why not
>>> > making something like an LTS PHP 7.x where all the legacy code would
>>> > work OK as long as practically possible and 8.x+ would be the future
>>> > of what the developers want and not what business wants? One who won't
>>> > upgrade due to the BC breaks also won't need the new features anyway
>>> > very realistically.
>>> >
>>>
>>> Please don't tie the notion of LTS with the idea that a new major can
>>> break
>>> BC at will or create larger scale breaks because the previous major has
>>> extended support.  Sooner or later that will end up back at the ++ idea
>>> and
>>> fragmentation encouraged by the language is a bad idea.
>>>
>>
>> Not sure you are really seeing the goal...
>>
>> Why is LTS not a good idea?
>>
>
> I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
> shipping larger scale BC breaks, such as the changes suggested in the last
> couple of "contentious" RFCs in a major version because "hey, we have a LTS
> version you can use that until you're ready to deal with the backlog of BC
> breaks created" is a bad idea.
>

> For the record, I happen to agree with as these RFCs would have minimal
> impact on my day-to-day work, but having also been in the role of a
> maintainer of open source libraries and applications I also grasp why these
> types of changes can be problematic to the ecosystem (both end users of
> those libraries and applications and the maintainers of them) and wouldn't
> jump the gun to ship them without careful consideration.
>

Most of these changes wouldn't have been problematic to you if the language
has prevented you from writing what we can now consider bad code, so please
allow the new PHP developer that newly start using PHP to not follow that
your path that will/might hunt him later in the future...

There a notices, warning and errors to inform you that this shouldn't have
been the use case of this feature and you chose to ignore it and now, we
are simplifying things and making those your errors teach you how to write
proper codes in the future, you're objecting.. Why not just stay in PHP 7.x?

Or were you implying you want hitch-free, no-modification upgrade to PHP 8
from PHP 7.0?
If yes, follow the best practices and not suppress error notices.

Just My Opinion

Michael Babker

6 years ago

On Thu, Sep 12, 2019 at 2:17 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> Most of these changes wouldn't have been problematic to you if the
> language has prevented you from writing what we can now consider bad code,
> so please allow the new PHP developer that newly start using PHP to not
> follow that your path that will/might hunt him later in the future...
>
> There a notices, warning and errors to inform you that this shouldn't have
> been the use case of this feature and you chose to ignore it and now, we
> are simplifying things and making those your errors teach you how to write
> proper codes in the future, you're objecting.. Why not just stay in PHP 7.x?
>
> Or were you implying you want hitch-free, no-modification upgrade to PHP 8
> from PHP 7.0?
> If yes, follow the best practices and not suppress error notices.
>

We're clearly talking past one another so I will be going back to work
after this response.

I am not saying anything about whether the warnings RFC should pass or
fail, or if it makes my code good or bad.  I responded explicitly to one
idea about creating a LTS version that might somehow make it easier for
RFCs like this one to be accepted because users could basically be
encouraged to stay on the LTS version if the new major version introduces
too many breaking changes, which I think is bad justification for creating
a LTS version.  I'm not sure how that equates to my code being good or bad
or whether I am following someone else's recommended best practices, but
that was never the point of discussion.

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 8:11 PM Michael Babker <michael.babker@gmail.com>
> wrote:
>
> > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com>
> > wrote:
> >
> >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <
> michael.babker@gmail.com>
> >> wrote:
> >>
> >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com>
> >>> wrote:
> >>>
> >>> > Just a dumb idea, since there clearly is a majority in favor of the
> >>> > change with these warnings and strictness and all that now... Why not
> >>> > making something like an LTS PHP 7.x where all the legacy code would
> >>> > work OK as long as practically possible and 8.x+ would be the future
> >>> > of what the developers want and not what business wants? One who
> won't
> >>> > upgrade due to the BC breaks also won't need the new features anyway
> >>> > very realistically.
> >>> >
> >>>
> >>> Please don't tie the notion of LTS with the idea that a new major can
> >>> break
> >>> BC at will or create larger scale breaks because the previous major has
> >>> extended support.  Sooner or later that will end up back at the ++ idea
> >>> and
> >>> fragmentation encouraged by the language is a bad idea.
> >>>
> >>
> >> Not sure you are really seeing the goal...
> >>
> >> Why is LTS not a good idea?
> >>
> >
> > I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
> > shipping larger scale BC breaks, such as the changes suggested in the
> last
> > couple of "contentious" RFCs in a major version because "hey, we have a
> LTS
> > version you can use that until you're ready to deal with the backlog of
> BC
> > breaks created" is a bad idea.
> >
>
>
> > For the record, I happen to agree with as these RFCs would have minimal
> > impact on my day-to-day work, but having also been in the role of a
> > maintainer of open source libraries and applications I also grasp why
> these
> > types of changes can be problematic to the ecosystem (both end users of
> > those libraries and applications and the maintainers of them) and
> wouldn't
> > jump the gun to ship them without careful consideration.
> >
>
> Most of these changes wouldn't have been problematic to you if the language
> has prevented you from writing what we can now consider bad code, so please
> allow the new PHP developer that newly start using PHP to not follow that
> your path that will/might hunt him later in the future...
>
>

Many of us don't consider it bad code. I've also always initialized
variables when it was required (and many times when it wasn't) even though
I wasn't forced to do so. A lot of other people do as well. If it's so
important to you, start a program to teach people how you think they should
code.

> There a notices, warning and errors to inform you that this shouldn't have
> been the use case of this feature and you chose to ignore it and now, we
> are simplifying things and making those your errors teach you how to write
> proper codes in the future, you're objecting..

As has been discussed before, notices are not the same as warnings and
errors.  Also, if those things are so wonderful, why can't you use them to
catch the issues you are complaining you can't catch right now? Again, you
are telling me there is something out there which will allow you to force
yourself to write "good code" without forcing me to follow the same
restrictions. Yet, you still feel it's necessary to not use those tools,
and instead modify the entire language so that I am forced to follow what
you deem best practices, even if I don't?

> Why not just stay in PHP 7.x?
>
> Because other features that I want to utilize will also be added in PHP

8.

Or were you implying you want hitch-free, no-modification upgrade to PHP 8

> from PHP 7.0?
>

I never said that. Here we go again with the "I guess you are against all
BC breaks" nonsense. If BC breaks are required to add new functionality,
or, have a very minimal negative impact, then I don't have a problem with
them. This is not one of those cases. It changes a fundamental aspect of
the language, an aspect that many people actually like, and it doesn't add
any new features to the language, nor is it needed to add any new features
to the language.

> If yes, follow the best practices and not suppress error notices.
>
> Just My Opinion
>

--
Chase Peeler
chasepeeler@gmail.com

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson <oludonsexy@gmail.com> wrote:

> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <michael.babker@gmail.com>
> wrote:
>
> > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com>
> wrote:
> >
> > > Just a dumb idea, since there clearly is a majority in favor of the
> > > change with these warnings and strictness and all that now... Why not
> > > making something like an LTS PHP 7.x where all the legacy code would
> > > work OK as long as practically possible and 8.x+ would be the future
> > > of what the developers want and not what business wants? One who won't
> > > upgrade due to the BC breaks also won't need the new features anyway
> > > very realistically.
> > >
> >
> > Please don't tie the notion of LTS with the idea that a new major can
> break
> > BC at will or create larger scale breaks because the previous major has
> > extended support.  Sooner or later that will end up back at the ++ idea
> and
> > fragmentation encouraged by the language is a bad idea.
> >
>
> Not sure you are really seeing the goal...
>
> Why is LTS not a good idea?
> And, if the majority want this or that, can we just blow everything into
> full dictatorship where i can host my fork of PHP doing uncountable
> unwanted things i can call it..?
>
> Any which way, i think the majority of us are tired of writing bad codes,
> but since the language is allowing it we don't have choices than to spend
> some hours or weeks later debugging the wrong or right line we did that
> last "big mistake", who knows there might be another line smiling coz i
> haven't detected it...
>

I can write good code without sacrificing the flexibility provided by PHP.
Don't force ME to write code a specific way because you aren't disciplined
enough to not write bad code without the compiler forcing you to do things
a certain way.

Of all of the justifications for this RFC I've heard, "I can't stop writing
bad code as long as I'm allowed to" has to be the worst.

--
Chase Peeler
chasepeeler@gmail.com

Olumide Samson

6 years ago

On Thu, Sep 12, 2019 at 8:15 PM Chase Peeler <chasepeeler@gmail.com> wrote:

>
>
> On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson <oludonsexy@gmail.com>
> wrote:
>
>> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <michael.babker@gmail.com>
>> wrote:
>>
>> > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com>
>> wrote:
>> >
>> > > Just a dumb idea, since there clearly is a majority in favor of the
>> > > change with these warnings and strictness and all that now... Why not
>> > > making something like an LTS PHP 7.x where all the legacy code would
>> > > work OK as long as practically possible and 8.x+ would be the future
>> > > of what the developers want and not what business wants? One who won't
>> > > upgrade due to the BC breaks also won't need the new features anyway
>> > > very realistically.
>> > >
>> >
>> > Please don't tie the notion of LTS with the idea that a new major can
>> break
>> > BC at will or create larger scale breaks because the previous major has
>> > extended support.  Sooner or later that will end up back at the ++ idea
>> and
>> > fragmentation encouraged by the language is a bad idea.
>> >
>>
>> Not sure you are really seeing the goal...
>>
>> Why is LTS not a good idea?
>> And, if the majority want this or that, can we just blow everything into
>> full dictatorship where i can host my fork of PHP doing uncountable
>> unwanted things i can call it..?
>>
>> Any which way, i think the majority of us are tired of writing bad codes,
>> but since the language is allowing it we don't have choices than to spend
>> some hours or weeks later debugging the wrong or right line we did that
>> last "big mistake", who knows there might be another line smiling coz i
>> haven't detected it...
>>
>
> I can write good code without sacrificing the flexibility provided by PHP.
> Don't force ME to write code a specific way because you aren't disciplined
> enough to not write bad code without the compiler forcing you to do things
> a certain way.
>
> Of all of the justifications for this RFC I've heard, "I can't stop
> writing bad code as long as I'm allowed to" has to be the worst.
>
> Yea, that's just one of the popular reasons, there are more if you go on

Stack Overflow and see what this dynamism(my foot) has caused to real-world
codes and fortunes that has been lost due to it(Which i'm also a testimony
to the fact).

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 2:51 PM Peter Kokot <peterkokot@gmail.com> wrote:

> On Thu, 12 Sep 2019 at 20:35, Zeev Suraski <zeev@php.net> wrote:
> >
> > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote:
> >
> > >
> > >
> > > > 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)
> > >
> >
> > You're right.  The thing is this - as I said, the RFC process was
> designed
> > to address additions to the language - as is implied in numerous places
> > (both the part I quoted from the RFC itself, as well as elements in RFC
> > template as well as the RFC howto).  It was never meant to handle
> > deprecations - mainly because we simply weren't doing much of that back
> in
> > the days where it was introduced.  It was meant to resolve the issue at
> > hand at the time (and in the years leading up to it) - which is a formal
> > way to agree on which features make it in and which ones don't.
> > Now, over the years (and more and more as of late) - it started being
> used
> > for deprecations.  But these deprecations have become more and more
> extreme
> > recently in terms of their impact.  Of course I do think deprecations
> > should be allowed, like in any other language.  I do think we need to
> have
> > a higher bar for them in general (both in terms of a clear benefits and
> > required majority - as is implied in the Voting RFC) - but since we've
> > grown used to using 2/3 for them - and given the pro-deprecation bias of
> > the current composition of internals@ - I also realize it will be tough
> to
> > do.  But when dealing with deprecation proposals that are likely to
> effect
> > a very sizable subset of our userbase and codebase, and deal with some of
> > the most basic building blocks of the language - we simply can't start
> > using the same process.  We never have in the past (none of the
> > deprecations we voted on since 2013 comes even remotely close to the
> level
> > of impact of the two proposals that have been put forward to a vote in
> the
> > recent couple of months, and the more recent one clearly far outdoes the
> > prior one in terms of impact).
> >
> > Should we have 'woken up' many years ago when we started using the Voting
> > RFC for deprecations it wasn't meant to handle?  Probably.  It would have
> > been much easier to install a new mechanism.  But it doesn't mean we
> should
> > repeat the same mistake, now that it begins to be used to deprecate
> > mainstream language behaviors.
> >
> > In terms of telling one from the other - right now, I'm afraid it's a bit
> > like some other things that fall into the category of 'you know it when
> you
> > see it'.  I think few can deny that far-reaching effect of changing how
> > variables behave in a language, whether they think it's a change for the
> > better or for the worse.  But I think it *may* be possible to formally
> > define.  These are just random thoughts at this point - but we could
> have a
> > set of apps/frameworks that we use as a testing bed to check the level of
> > impact of a certain proposal.  If that impact is above a certain
> threshold
> > - it will be considered fundamental.  Of course, things like WordPress,
> > Joomla and MediaWiki would have to be a part of that - not just modern
> > frameworks.  It's still not ideal since it doesn't account for the
> majority
> > of PHP code out there which isn't Open Source - but it may be a start.
> > There may be other ways - such as letting folks run that analysis on
> their
> > own code behind the firewall and report results back.
> >
> > But there's also a simpler solution to this.  This 'can of worms' as
> Arvids
> > called it, wouldn't have been opened had we agreed to focus on extending
> > PHP instead of trying to replace it with something else.  This is what
> the
> > RFC process was meant to facilitate.  It still can, but for that, we need
> > to change the dynamics from a zero-sum game to a goal of a win/win.
> Yes, I
> > realize that I'm sounding like a broken record.  But call me naive - I'm
> > still hoping that given it obviously can be done from a technical
> > perspective (in a wide variety of ways too) - we can find the good will
> to
> > do it from a human perspective.
> >
> > Zeev
> >
> >
> > >
>
> Just a dumb idea, since there clearly is a majority in favor of the
> change with these warnings and strictness and all that now... Why not
> making something like an LTS PHP 7.x where all the legacy code would
> work OK as long as practically possible and 8.x+ would be the future
> of what the developers want and not what business wants? One who won't
> upgrade due to the BC breaks also won't need the new features anyway
> very realistically.
>
>

Someone that has a lot of uninitialized variables could definitely take
advantage of features like enums and union types (just to name a few). If
there were actually new, useful features that were dependent on such a
change, then I'd be much more open to the idea, if not outright in favor of
it. However, there aren't any new and useful features that are dependent on
the errors being thrown for uninitialized variables.

> Microsoft, Zend, and Red Hat have been showing that this is actually
> possible. How smart this is for the PHP progress is another story, but
> for the business it might be good to think about this also I guess:
> https://github.com/microsoft/php-src/releases
>
> So, to make some sort of a milestone with some of the versions -
> either 8 or 9 or something.
>
>
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Chase Peeler
chasepeeler@gmail.com

Remi Collet

6 years ago

Le 12/09/2019 à 20:51, Peter Kokot a écrit :

> Just a dumb idea, since there clearly is a majority in favor of the
> change with these warnings and strictness and all that now... Why not
> making something like an LTS PHP 7.x where all the legacy code would
> work OK as long as practically possible and 8.x+ would be the future
> of what the developers want and not what business wants? One who won't
> upgrade due to the BC breaks also won't need the new features anyway
> very realistically.
>
> Microsoft, Zend, and Red Hat have been showing that this is actually
> possible. How smart this is for the PHP progress is another story, but
> for the business it might be good to think about this also I guess:
> https://github.com/microsoft/php-src/releases
>
> So, to make some sort of a milestone with some of the versions -
> either 8 or 9 or something.

This is chicken and eggs problem

"Maintained because used" or "used because maintained" ?

PHP 7 was a very good version, with good BC, and speed of adoption is
quite good.

But some users still old 5.x

From download of my repo [1]

In January, ~35% for 5.6
In August, down to ~28%

IMHO, more BC breaks will mean more time to adapt code and more slow
adoption by users.

So Yes, we'll need a longer support time for 7.4, as we have extended
support for 5.6 by 1 year). Perhaps more will be needed for 7.4.

But yes, we are allowed to change things and dream of a perfect
language, like Perl 6...

Remi

[1] this are only numbers... from about 5k RPM download per day, and
probably artificially bigger for EOL versions, because I'm the only repo
to provide them.

Chase Peeler

6 years ago

On Thu, Sep 12, 2019 at 2:35 PM Zeev Suraski <zeev@php.net> wrote:

> On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote:
>
> >
> >
> > > 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)
> >
>
> You're right.  The thing is this - as I said, the RFC process was designed
> to address additions to the language - as is implied in numerous places
> (both the part I quoted from the RFC itself, as well as elements in RFC
> template as well as the RFC howto).  It was never meant to handle
> deprecations - mainly because we simply weren't doing much of that back in
> the days where it was introduced.  It was meant to resolve the issue at
> hand at the time (and in the years leading up to it) - which is a formal
> way to agree on which features make it in and which ones don't.
> Now, over the years (and more and more as of late) - it started being used
> for deprecations.  But these deprecations have become more and more extreme
> recently in terms of their impact.  Of course I do think deprecations
> should be allowed, like in any other language.  I do think we need to have
> a higher bar for them in general (both in terms of a clear benefits and
> required majority - as is implied in the Voting RFC) - but since we've
> grown used to using 2/3 for them - and given the pro-deprecation bias of
> the current composition of internals@ - I also realize it will be tough to
> do.  But when dealing with deprecation proposals that are likely to effect
> a very sizable subset of our userbase and codebase, and deal with some of
> the most basic building blocks of the language - we simply can't start
> using the same process.  We never have in the past (none of the
> deprecations we voted on since 2013 comes even remotely close to the level
> of impact of the two proposals that have been put forward to a vote in the
> recent couple of months, and the more recent one clearly far outdoes the
> prior one in terms of impact).
>
> Should we have 'woken up' many years ago when we started using the Voting
> RFC for deprecations it wasn't meant to handle?  Probably.  It would have
> been much easier to install a new mechanism.  But it doesn't mean we should
> repeat the same mistake, now that it begins to be used to deprecate
> mainstream language behaviors.
>
> In terms of telling one from the other - right now, I'm afraid it's a bit
> like some other things that fall into the category of 'you know it when you
> see it'.  I think few can deny that far-reaching effect of changing how
> variables behave in a language, whether they think it's a change for the
> better or for the worse.  But I think it *may* be possible to formally
> define.  These are just random thoughts at this point - but we could have a
> set of apps/frameworks that we use as a testing bed to check the level of
> impact of a certain proposal.  If that impact is above a certain threshold
> - it will be considered fundamental.  Of course, things like WordPress,
> Joomla and MediaWiki would have to be a part of that - not just modern
> frameworks.  It's still not ideal since it doesn't account for the majority
> of PHP code out there which isn't Open Source - but it may be a start.
> There may be other ways - such as letting folks run that analysis on their
> own code behind the firewall and report results back.
>
> But there's also a simpler solution to this.  This 'can of worms' as Arvids
> called it, wouldn't have been opened had we agreed to focus on extending
> PHP instead of trying to replace it with something else.  This is what the
> RFC process was meant to facilitate.  It still can, but for that, we need
> to change the dynamics from a zero-sum game to a goal of a win/win.  Yes, I
> realize that I'm sounding like a broken record.  But call me naive - I'm
> still hoping that given it obviously can be done from a technical
> perspective (in a wide variety of ways too) - we can find the good will to
> do it from a human perspective.
>
>

Exactly. I think it's telling that the majority of the rebuttals to
arguments against the RFC are to claim that we're against moving the
language forward, against BC breaks, etc. That couldn't be further from the
truth. We do want to move the language forward. We want do that by adding
to the language, and not changing it into an entirely different language.

> Zeev
>
>
> >
>

--
Chase Peeler
chasepeeler@gmail.com