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
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
чт, 12 сент. 2019 г. в 16:53, Dan Ackroyd Danack@basereality.com:
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--
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
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".
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
-----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 behaviorsThe 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
Hi Zeev,
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
-----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 behaviorsIf 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
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.
-----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 behaviorsIf 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
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
-----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 behaviorsIf 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
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.comScott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises-----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 behaviorsIf 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
--
--
--
Chase Peeler
chasepeeler@gmail.com
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
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.comScott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises-----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 behaviorsIf 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
--
--
--
Chase Peeler
chasepeeler@gmail.com
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.
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
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.
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
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?
On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay php-lists@koalephant.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.comPlease, 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?
First of all, I wasn't as involved with this list back then as I was now.
However, I can see a fundamental difference in the two. Not needing to
initialize variables just for the sake of initializing them (e.g. just
doing $i++ without $i=0 before it) is something that is going to behave as
expected almost all of the time. When it doesn't, you can easily initialize
$i to a non-zero value, or, you can initialize it to zero if you want - it
doesn't hurt anything.
An undefined constant getting converted to a string, though, is much less
likely to be the intended behavior. String literals are required to be in
quotes. Constants can never be in quotes. Assuming that the token that
looks like a constant, but can't be because the constant didn't exist, so,
we'll pretend it's a string even though it doesn't match the proper syntax
for such a token is drastically different than assuming the variable you
are incrementing that wasn't initialized is 0, or, that the variable you
are concatenating to, but wasn't initialized, is an empty string.
Finally, let's pretend that the undefined constants RFC was a horrible RFC
that shouldn't have passed. The fact that it did has no impact on whether
or not this RFC should pass.
--
Chase Peeler
chasepeeler@gmail.com
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.comPlease, 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?
First of all, I wasn't as involved with this list back then as I was now. However, I can see a fundamental difference in the two. Not needing to initialize variables just for the sake of initializing them (e.g. just doing $i++ without $i=0 before it) is something that is going to behave as expected almost all of the time. When it doesn't, you can easily initialize $i to a non-zero value, or, you can initialize it to zero if you want - it doesn't hurt anything.
An undefined constant getting converted to a string, though, is much less likely to be the intended behavior. String literals are required to be in quotes. Constants can never be in quotes. Assuming that the token that looks like a constant, but can't be because the constant didn't exist, so, we'll pretend it's a string even though it doesn't match the proper syntax for such a token is drastically different than assuming the variable you are incrementing that wasn't initialized is 0, or, that the variable you are concatenating to, but wasn't initialized, is an empty string.
Finally, let's pretend that the undefined constants RFC was a horrible RFC that shouldn't have passed. The fact that it did has no impact on whether or not this RFC should pass.
--
Chase Peeler
chasepeeler@gmail.com
Apologies if you thought I was specifically replying to you Chase, I simply hit reply-all to the last message I had.
The RFC I referred to explicitly describes the use-case for the (mis-)feature it removed:
The current behaviour appears to have been added as an attempt to guess the user's intention, and continue gracefully.
Sounds familiar, doesn’t it? “If I write $foo++ and $foo is undefined, it should know what I mean”.
The value of keeping the current behaviour would be for programs written to deliberately take advantage of it. In particular, I have seen sample code of the form $_GET[bar] where bar is taken to be the string key bar.
So, it clearly was (ab)used.
IMO this also flies in the face of the “we can’t change behaviour” argument - bare word strings were added around 20 years ago, and yet not a single person thought it worthwhile voting against the deprecation and removal of this behaviour?
I'm sure that some people wrote code like this, expecting it to always work
in PHP:
if ($some_condition) define("HELLO", 0);
if (HELLO) { var_dump("got here"); }
The equivalent, relying on buggy behaviour, PHP code looks like
if ($some_condition) $hello = 1;
if (!$hello) { var_dump("got here"); }
If preventing undefined constants wasn't a fundamental change to the
language, neither is preventing undefined variables.
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
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)
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
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)
No, I think you misunderstood. I said "What if Java did XYZ" - The reply
was "If 95% of userland Java developers supported such a change..." That
implies that 95% of userland PHP developers support the changes in the RFC.
It wouldn't make sense to say "Well, if 95% of Java userland developers
supported the change, then it would make sense, just like we should pass
this RFC that 45% of PHP userland developers support"
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
--
Chase Peeler
chasepeeler@gmail.com
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
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
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 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...
#jmtcw
-Mike
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 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..
Can you please stop speaking for what you think they should do? Only they
can speak for what they should do.
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...
Yes, but, there are going to be other features in PHP 8 that won't break
existing code and are beneficial. They may be forced to stick with PHP 7,
but don't act like that is a perfectly acceptable option without any
downsides.
#jmtcw
-Mike
--
Chase Peeler
chasepeeler@gmail.com
I think they could switch to using null instead, or perhaps get something else to differentiate what they have initialized or not,
Perhaps, but switching the code requires finding the right people to do the work and then funding the changes.
A lot of WordPress code marginally maintained is at best — especially WordPress sites. That differs from what it sounds like are the practices of those who are arguing for enforced strictness here on this list.
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..
Hopefully my words did not imply that. I think I instead stated that they would likely never upgrade.
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"?
It is absolutely an assumption. Based on my experience. But YMMV.
That said, I can give you stats for how many WordPress plugins there are on the WordPress repository, around 68,000. And in my experience a sizable percentage of them would break with these changes.
Whether or not the PHP community cares about breaking a large number of WordPress sites or not is up to those of you who get to vote. I just commented to include this perspective since I have not seen anyone else mention WordPress on the list recently.
It's up to them, PHP 7 is still available and will always be available for them to use...
Yes. But of course, at some point PHP 7 will no longer be officially supported.
At which point PHP7 users will be forced to decide between support and choosing a support direction for their future.
And again, #jmtcw
-Mike
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
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/8mB8Bvar_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.even without a statistics to back the word is plainfully meaningless...
I guess we tend to use the word "HUGELY","NEVER","EVER","COMPANY", etc
wrongly on the list just to prove some points.
And, we're better off than that IMO...
Regards,
Lynn van der Berg
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/8mB8Bvar_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.It's not a matter of won't upgrade, but that they can't upgrade. If
Wordpress decides to take their time supporting PHP 8, wordpress users
won't have any option but to wait on upgrading.
Regards,
Lynn van der Berg
--
Chase Peeler
chasepeeler@gmail.com
It's not a matter of won't upgrade, but that they can't upgrade. If Wordpress decides to take their time supporting PHP 8, wordpress users won't have any option but to wait on upgrading.
To be clear, WordPress core upgrading to support PHP won't be a big issue. And WordPress core code has actually improved significantly in recent years.
Upgrading the ~68,000 open source plugins available on wordpress.org http://wordpress.org/, thousands of commercial plugins, and and an untold number of custom-developed bespoke plugins and custom themes is where the concern lies.
-Mike
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 https://3v4l.org/8mB8Bvar_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.It's not a matter of won't upgrade, but that they can't upgrade. If Wordpress decides to take their time supporting PHP 8, wordpress users won't have any option but to wait on upgrading.
Regards,
Lynn van der Berg--
Chase Peeler
chasepeeler@gmail.com <mailto:chasepeeler@gmail.com
Upgrading the ~68,000 open source plugins available on wordpress.org http://wordpress.org/, thousands of commercial plugins, and and an untold number of custom-developed bespoke plugins and custom themes is where the concern lies.
Many of these are ticking bombs - unmaintained extensions with possible security issues. Right now the biggest problem of WordPress ecosystem is
quality of community extensions and themes. Cutting of all old and unmaintained extensions may be not that bad...
Regards,
Robert Korulczyk
Many of these are ticking bombs - unmaintained extensions with possible security issues.
Totally agree.
Right now the biggest problem of WordPress ecosystem is quality of community extensions and themes.
Being intimately involved in the WordPress ecosystem, I do not know If it is the biggest problem.
But I digress...
Cutting of all old and unmaintained extensions may be not that bad...
It depends on who you ask if it is bad or not. I think that many on this list would think it is a good thing. OTOH, I think many people who have working websites that currently use one of these plugins and who do not have developers on staff would think it is a very bad thing. Especially if such a change could cost them a significant unplanned amount of money and hassle to resolve.
Which brings up an important point. There is a big difference between the plugins in the WordPress.org http://wordpress.org/ repo that might have security issues I think the WordPress Core team would be open to sunsetting any plugins that are objectively found to have security issues, or even major PHP compatibilities.
OTOH, given that WordPress is over 1/3rd of the web that means many of these plugins are active on working sites, sites where their web host might encourage them to upgrade to PHP8 when PHP 7 is no longer supported.
It is those people who are likely to be most negatively affected, and the vast majority of them will never have hired a developer in their life let alone understand why a handful of people decided to "break their site" without them having any say in the matter.
#fwiw
-Mike
P.S. Again, I want to clarify I am not saying what the PHP core team should do. I am simply relaying what I think the ramifications are likely to be — based upon my experience with WordPress since 2010 and PHP since 2008 — if breaking changes are introduced into PHP 8. It is up to the voting members to actually decide what will happen.
Upgrading the ~68,000 open source plugins available on wordpress.org http://wordpress.org/, thousands of commercial plugins, and and an untold number of custom-developed bespoke plugins and custom themes is where the concern lies.
Many of these are ticking bombs - unmaintained extensions with possible security issues. Right now the biggest problem of WordPress ecosystem is
quality of community extensions and themes. Cutting of all old and unmaintained extensions may be not that bad...Regards,
Robert Korulczyk
I'm thinking this thread is receiving much attention than really required.
Irrespective of the left and right argument, I think everyone wants a
better language, the leftist are just arguing on a very lazy fact, not that
they don't see anything bad in their wrong argument they are all just
trying to hide behind "We know it is bad or can be devastating, let's just
leave it as it is and hope nobody ever have reasons to clean it since it is
still working" but me and those rightist are all like, this is wrong let's
save billions of codes that could still be added to this buggy behavior
than leaving it and hoping it would be one of the best dynamism people want
from PHP.
How does bug translate to dynamism?
Why were there notices if something wasn't wrong somewhere with the
behavior?
If I'm to argue as php-src(being human), I would never allow those leftist
to use me to write code again coz it is highly straining to pretend to know
what an undefined variable meant( to be an int or string, or even an
object) or even if it was a typo.
We are straining the language performance even more by making it guess what
the undefined variable would have been.
Even a string would still go up as integer the moment you add ++($i++) to
it.
Why don't you people see it is safe and would be in everyone's best
interests if we could clean this garbage behavior once and for all to live
peacefully, and possibly reduce the amount of baggage behavior lying around
in millions of codes out there, coz the counts increase every single day
because everyone thinks it is the right behavior yet their error_log keep
on getting notices?
Zeev said the RFC was never meant to deprecate things and as such the
voting would eventually not pass on to implementation even if it was
accepted -
"why then do you vote no on the RFC if it was never a valid vote to count?"
I think voting on the RFC validates the RFC for all you've voted it for
which means it's a valid way to deprecate features, else all formerly
deprecated features can be reverted since they are invalidated by the
current situation(or eye opening statement you just made).
I think we all need to see from the right spot how many people and code we
would save if this garbage were reported as Warning or error as early as
possible than waiting for never yet still giving me notice in my error_log
everytime PHP hit an undefined variable.
One thing some people are forgetting is that this is an open source
community and people(myself included) coming here to pull, push, commit,
test, manage and even join the mailing list are not getting paid by anyone
to do so(there might be an exception), and being an open source project we
all need to agree to disagree no one has any authority over anyone.
If there's been some laid out rules about some chairmen and the authorities
they posses to always swing things in their favor, I'm very sure this
project would have been dead on arrival( while there are so many projects
wanting attention), since a open source project needs help from
contributors I think we all need to think properly about rules or
guidelines that might hurt the project's contribution.
I don't pray to see PHP 9 timelines not posted by anyone(coz there's no one
around to do so) or even php-src to be one of those languages where their
contribution reduced drastically based on some people's bad influence
affecting the other contributors.
Let's argue rightly and expect other people to not agree with us, that's
the default.
Thanks,
Samson(noobshow)
Upgrading the ~68,000 open source plugins available on wordpress.org <
http://wordpress.org/>;, thousands of commercial plugins, and and an
untold number of custom-developed bespoke plugins and custom themes is
where the concern lies.Many of these are ticking bombs - unmaintained extensions with possible
security issues. Right now the biggest problem of WordPress ecosystem is
quality of community extensions and themes. Cutting of all old and
unmaintained extensions may be not that bad...Regards,
Robert Korulczyk
On Fri, Sep 13, 2019 at 11:59 AM Olumide Samson oludonsexy@gmail.com
wrote:
"We know it is bad or can be devastating
Actually, that's not at all what we're saying.
I think that doing something like @$foo++ is absolutely fine. Many others
on this (and related) threads think so too. I find all the 'improvements'
with littered questionmarks to be a giant step backwards.
Why were there notices if something wasn't wrong somewhere with the
behavior?
We've been through that. You may want to take a look again at the
definition of what a notice is.
Zeev said the RFC was never meant to deprecate things and as such the
voting would eventually not pass on to implementation even if it was
accepted -"why then do you vote no on the RFC if it was never a valid vote to count?"
Which is precisely why I didn't vote on that particular part of the RFC so
far. That said - I am considering voting a 'keep notice' on it, and I'll
briefly explain why.
The choice between moving to a warning or keeping a notice is completely
legit, and moving it to a warning may even a good idea (mainly due to error
reporting defaults, even though a notice is technically more appropriate;
main worry is that it might constitute a reason for others in the future to
say it's no longer legitimate, and therefore it's no big deal to deprecate
it). The part of moving to an error exception is not - as it is a radical
change in functionality (and not a simple 'reclassification of errors'),
aka deprecation.
If I do choose to vote to one of the other two options - it should be taken
in the context of choosing between the two valid options, and not as any
sort of validation on the invalid one.
Zeev
Indeed, for the case of local variables that were undefined before,
this can usually be fixed in a straightforward way by initializing to
NULL.
The goal here is to get rid of the error or notice while preserving
the original behavior (even if it was buggy).
This is IF this is your own custom code, or you have a strategy for
maintaining patches on 3rd party code. (which you probably should).
Another problem which has not been talked about much is code like
this, which I have seen in multiple legacy code bases for Drupal 7
projects. Code like this is not considered good practice in Drupal 7,
but it does exist.
$element['field_category'][LANGUAGE_NONE][0]['#entity']->field_author_label['en'][0]['value'];
This is crying for "trying to access property of non-object". Because
the values in $element were usually created "elsewhere", and who knows
if the value at that position is an object?
Even worse: This might go unnoticed 99% of the time, but in a specific
edge case the value might not be initialized and the website would
crash with error in PHP8.
The "minimal fix" to preserve behavior 1:1 is to call if (isset()) or
if (!empty()) on the whole thing before every such construct, even if
at the moment you are not aware of cases where it might fail. In the
"else" case, you do whatever would have happened before if the value
was NULL.
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/8mB8Bvar_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
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.
This raises an interesting, tangential point. Who is PHP for?
One can argue that WordPress, with it powering 34% of the web (source:
wordpress.org) represents more than 50% of PHP users, and therefore
aligning the language to how they use it would be sensible, as they are the
majority of users. PHP and WordPress have had a symbiotic relationship, the
success of one increasing the success of the other.
Those who wish PHP was more advanced and different (and I count myself
amongst them) do well to remember that PHP has become extraordinarily
successful in spite of the flaws now perceived. It's a good language that
fills a niche even server-side JavaScript hasn't usurped. There is no shame
in a language staying true to its roots, plateauing and eventually dying a
death (cf Perl 5). I don't want that, but it's a valid route. And the
communities that use PHP in a way many on this list look down on will be
thankful to continue to have a language they can use, can hack with, and
get stuff done. Even if there's a few extra bugs.
The rest of us, meanwhile, have the opportunity to use a programming
language that's closer to whatever we feel is a "proper" language (a vibe I
pick up in the "they look down on us" and "I'd rather PHP was more like X"
messages). If you're going to have to justify upgrading your code, why not
propose a rewrite in another language? One can sell it on the fact it won't
have the flaws regularly brought up on this list - like warnings instead of
exceptions, or two opening tags. Or, despite the fuss on-list, do those who
decide how the next project will be written/the current one rewritten, not
care to the same extent, and other factors will influence their choice?
Personally I cannot wait for new features to be added, but feel our
heritage is as important as the future. Jordi expresses my feelings, and I
quote him:
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. [...] So what do we gain exactly?
Peter
On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer phpmailinglists@gmail.com
wrote:
One can argue that WordPress, with it powering 34% of the web (source:
wordpress.org) represents more than 50% of PHP users, and therefore
aligning the language to how they use it would be sensible, as they are the
majority of users. PHP and WordPress have had a symbiotic relationship, the
success of one increasing the success of the other.
How many of those are actually developers? Because the way I understand
this numbers, "powering the web", that doesn't mean 34% are also
developers. It wouldn't surprise me if a big portion of these applications
could've also be a system written in another language, deployed, plugins
installed, added some themes and done, no PHP knowledge required.
Regards,
Lynn van der Berg
On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer phpmailinglists@gmail.com
wrote:One can argue that WordPress, with it powering 34% of the web (source:
wordpress.org) represents more than 50% of PHP users, and therefore
aligning the language to how they use it would be sensible, as they are
the
majority of users. PHP and WordPress have had a symbiotic relationship,
the
success of one increasing the success of the other.How many of those are actually developers? Because the way I understand
this numbers, "powering the web", that doesn't mean 34% are also
developers. It wouldn't surprise me if a big portion of these applications
could've also be a system written in another language, deployed, plugins
installed, added some themes and done, no PHP knowledge required.
Many are. The WP developer ecosystem footprint is at the same order of
magnitude as (and in some geographics larger than) that of 'generic' PHP -
in terms of conferences and conference sizes, usergroups, available jobs,
etc. I don't think any of us can pull numbers off of our sleeves - but the
vast majority of folks who deploy WordPress sites that I bumped into also
deal with at least some custom PHP code - and are responsible for the
deployment whether they wrote it or not. It's true that there are many
agencies and freelancers that do a lot more than one site. But it's also
true that the WordPress numbers are enormous even if we cut them down by a
factor of 10 (which I believe would be big exaggeration)
And of course, the can be said about PHP apps in general - many developers
produce a lot more than just one site. So while there's no 1:1 correlation
between the number of sites and the number of developers, it's true for
both WP and generic PHP (perhaps in slightly different scales). And of
course #2 - we're not only talking about WordPress - non-WP developers will
be affected by this as well.
Zeev
How many of those are actually developers? Because the way I understand this numbers, "powering the web", that doesn't mean 34% are also developers. It wouldn't surprise me if a big portion of these applications could've also be a system written in another language, deployed, plugins installed, added some themes and done, no PHP knowledge required.
Most WordPress users are not programmers.
Which is why introducing breaking changes to PHP will potentially affect them so negatively; because they have no programmers on staff nor any skill to fix the problem. Which means they will have to hire expensive programmers — like me!!! — to fix a problem that from their perspective they do not understand nor will even recognize a benefit when the code is "fixed."
Again, I am just presenting this perspective on this list. Those who vote on this list will decide if breaking WordPress end-user's site bothers them or not.
-Mike
P.S. I am writing during a break at a WordPress conference, ironically.
Zeev,
I'm going to keep this really short and simple ...
You don't have the authority to make unilateral decisions for PHP,.
Nothing you are saying is going to have any effect, the people who actually
work on the language will merge whatever is voted in.
Cheers
How many of those are actually developers? Because the way I understand
this numbers, "powering the web", that doesn't mean 34% are also
developers. It wouldn't surprise me if a big portion of these applications
could've also be a system written in another language, deployed, plugins
installed, added some themes and done, no PHP knowledge required.Most WordPress users are not programmers.
Which is why introducing breaking changes to PHP will potentially affect
them so negatively; because they have no programmers on staff nor any skill
to fix the problem. Which means they will have to hire expensive
programmers — like me!!! — to fix a problem that from their perspective
they do not understand nor will even recognize a benefit when the code is
"fixed."Again, I am just presenting this perspective on this list. Those who vote
on this list will decide if breaking WordPress end-user's site bothers them
or not.-Mike
P.S. I am writing during a break at a WordPress conference, ironically.
Zeev,
I'm going to keep this really short and simple ...
I'll do the same.
You don't have the authority to make unilateral decisions for PHP,.
Neither does anybody else on this list. Not even a plurality or a majority of folks on this list has the authority to apply the RFC process to something it was clearly not designed to handle.
Nothing you are saying is going to have any effect, the people who actually
work on the language will merge whatever is voted in.
Without getting to the technicalities, simply put, no.
Zeev
Zeev,
Without getting to the technicalities, simply put, no.
I'm not sure what you intend to do to stop it.
Once again, I remind you that you don't have the authority that your
behaviour communicates you have, at all.
I wasn't starting a conversation, I was communicating facts, and I'm
finished communicating with you.
Cheers
Joe
Zeev,
I'm going to keep this really short and simple ...
I'll do the same.
You don't have the authority to make unilateral decisions for PHP,.
Neither does anybody else on this list. Not even a plurality or a
majority of folks on this list has the authority to apply the RFC process
to something it was clearly not designed to handle.Nothing you are saying is going to have any effect, the people who actually
work on the language will merge whatever is voted in.Without getting to the technicalities, simply put, no.
Zeev
Zeev,
Without getting to the technicalities, simply put, no.
I'm not sure what you intend to do to stop it.
I sincerely hope reason will prevail and we won't have to find out (as I was hoping this part of the RFC won't be put up for a vote so that we wouldn't be in this mess to begin with). I am not looking forward to it - but we will not be depreciating fundamental language functionality regardless of the results of this or any other RFC - as RFCs have no mandate to do that. That is a statement of fact.
Cheers,
Zeev
Hello Zeev
Would you mind sharing with us why you specifically would be able to single handedly decide what gets merged into PHP and what not?
Kind regards
Brent
Zeev,
Without getting to the technicalities, simply put, no.
I'm not sure what you intend to do to stop it.
I sincerely hope reason will prevail and we won't have to find out (as I was hoping this part of the RFC won't be put up for a vote so that we wouldn't be in this mess to begin with). I am not looking forward to it - but we will not be depreciating fundamental language functionality regardless of the results of this or any other RFC - as RFCs have no mandate to do that. That is a statement of fact.
Cheers,
Zeev
How many of those are actually developers? Because the way I understand this numbers, "powering the web", that doesn't mean 34% are also developers. It wouldn't surprise me if a big portion of these applications could've also be a system written in another language, deployed, plugins installed, added some themes and done, no PHP knowledge required.
Most WordPress users arenot programmers.Which is why introducing breaking changes to PHP will potentially affect them so negatively; because they have no programmers on staff nor any skill to fix the problem. Which means they will have to hire expensive programmers — like me!!! — to fix a problem that from their perspective they do not understand nor will even recognize a benefit when the code is "fixed."
Again, I am just presenting this perspective on this list. Those who vote on this list will decide if breaking WordPress end-user's site bothers them or not.
Something which does not help here is the way WordPress enforces
upgrades that may not be compatible with all elements of the themes that
the user currently has active. I AM a programmer rather than a web
designer and am having trouble keeping WordPress sites stable. To that
end I have decided simply to freeze at PHP7.2 for various reasons but
WordPress is now complaining that the version of PHP is out of date. One
just can't win ... some of the WordPress sites themes will not even work
with PHP7 (or WP5) at all. So we DO need an LTS version of PHP that
will run perfectly functional websites for the next ten years while
others create the next replacement for the likes of WordPress by moving
framework functionality inside PHP ... Much of the discussion on new
features cut across the ways frameworks already handle that
functionality ...
--
Lester Caine - G8HFL
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
Am 13.09.2019 um 09:41 schrieb Lester Caine lester@lsces.uk:
Those who vote on this list will decide if breaking WordPress end-user's site bothers them or not.
That's something too few people on this list seem to be aware of:
Breaking other people's perfectly functional code because you believe in a different coding style is not something which should be done easily.
So we DO need an LTS version of PHP that will run perfectly functional websites for the next ten years while others create the next replacement for the likes of WordPress by moving framework functionality inside PHP ...
I agree!
Which means there will be additional burden on the PHP core developers as there will be another version to back port security fixes to for a long time. Also not a decision to be made lightly.
While I do like democracy I also agree with Zeev that it is too easy for people to vote yes on a breaking change even if they didn't think it through.
So if you voted yes for any change of a notice/warning to an exception (which will break things) please reconsider!
Is it really worth it? And if you really think so, could we make it opt-in? Or at least globally opt-out-able?
- Chris
On Fri, Sep 13, 2019 at 10:10 AM Christian Schneider cschneid@cschneid.com
wrote:
Am 13.09.2019 um 09:41 schrieb Lester Caine lester@lsces.uk:
Those who vote on this list will decide if breaking WordPress
end-user's site bothers them or not.That's something too few people on this list seem to be aware of:
Breaking other people's perfectly functional code because you believe in a
different coding style is not something which should be done easily.So we DO need an LTS version of PHP that will run perfectly functional
websites for the next ten years while others create the next replacement
for the likes of WordPress by moving framework functionality inside PHP ...I agree!
Which means there will be additional burden on the PHP core developers as
there will be another version to back port security fixes to for a long
time. Also not a decision to be made lightly.
I would think that this is exactly what a company like Zend would charge
their customers for. Microsoft is doing it for free for 5.6, I imagine for
their bigger Azure customres here: https://github.com/microsoft/php-src
LTS versions should not be the responsibility of the core developers, they
are the responsibile of a legal entity with financial means that either
directly sponsors the OSS project (Ubuntu) or is downstream of the project
(RedHat).
PHP is entirely a community project of volunteers that is already hanging
by a thread given the workload.
While I do like democracy I also agree with Zeev that it is too easy for
people to vote yes on a breaking change even if they didn't think it
through.So if you voted yes for any change of a notice/warning to an exception
(which will break things) please reconsider!
Is it really worth it? And if you really think so, could we make it
opt-in? Or at least globally opt-out-able?
- Chris
Is it really worth it?
It's absolutely worth it. Stopping execution flow at erroneous or
ambiguous statements is an essential part of secure, reliable programming.
A notice or warning offers no protection at all. Unless you've taken
some very specific steps, your program will continue operating as if
they never happened, even if that notice or warning was clearly a high
probability of being a bug.
And if you really think so, could we make it opt-in?
People should not have to opt in to common sense defaults. If I sell you
a car, you shouldn't have to opt in to having the bolts on your tyres
fastened on tight enough that the wheels don't fall off the moment you
hit motorway speed.
Or at least globally opt-out-able?
Let's not. Never again should an option like enable_short_tags exist. If
you want a per-file opt out, the notion of
declare(sloppy=1);
Has already been jokingly proposed, and I would personally have no
problem with it if people want to opt-in to less reliable enforcement...
but once again, I stress that the defaults should always be best-practices.
--
Mark Randall
the notion of
declare(sloppy=1);
Has already been jokingly proposed,
Who ever said it was a joke proposal? :-P
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.
Whatever the case, changing warnings to errors would require fixing working code. And for many people, that would requiring investing lots of money.
However, I think most people agree that the quality of Wordpress code and Plugins is highly debatable.
That is probably very true, but it is orthogonal to whether or not certain potential changes in PHP would cause expense changes to be implemented in order for WordPress users to upgrade to an incompatible PHP8.
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.
I don't like the idea of not being able to progress because Wordpress users won't upgrade PHP.
I am not making that argument. I am simply pointing out that the changes being considered will almost certainly break a large percentage of WordPress sites and fixing those site will likely be very costly for site owners.
So it is up to those who have a vote on the future of PHP to decide if a large number of broken WordPress matters to them or not. I am just a messenger.
-Mike
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)...
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
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
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
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:
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:
- Who then has the mandate to do so?
- 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 |
+---------------------------------------------------------------------+
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
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
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.
On Thu, Sep 12, 2019 at 8:00 PM Michael Babker michael.babker@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...
On Thu, Sep 12, 2019 at 8:00 PM Michael Babker michael.babker@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.
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
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.
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
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
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
I think it's all up to you to decide if those features you need would be
worth it moving to PHP 8(perhaps helping you clean up some codes i would
seem as bad practice IMO) or those features are not worth cleaning up for(
then you can stay on PHP 7, even 5 for as long as you wan to)...
In all of these, those who would upgrade would do so and those who won't
would never upgrade coz they don't see good reasons to or such codes are
not more in maintenance...
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
I think i also have some stuffs to do off this list, perhaps i might check
the list later before bed or wheni get home.
Have a nice time voting as you deem fit and as you best think would be good
for you and everyone(maybe?).
Hi guys,
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.
One problem that needs to be understood is that PHP is used by a lot of
users.
Because it's easy to pick up and you have fast feedback it probably have a
higher percentage of juniors than average.
How language was 10 years ago it didn't helped them much in learning and
they did lot of mistakes. Some of those mistakes cost companies lots of
money and, in time, people got to the conclusion that PHP is bad.
This is a very important thing!, Yes you can write working great code in
PHP but it's very easy to write working bad code as well. And it's not
about you and me or the other persons chatting here, it's about the rest of
the world.
PHP improved on it's bad image in the later years but this needs to
continue. IMO, one thing that we need to also do is to make the language
image better.
With this in mind, I believe the "undefined variable" error will be a step
forward.
It's not about if you don't consider it bad code and that apparently the
majority consider it good.
It's that if language wouldn't allow you to write that code it will benefit
the language image and the rest of the PHP comunity.
Also, I would also like to remind of this:
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
I think some parts might have been violated multiple time in this thread.
Regards,
Alex
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
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
On Thu, Sep 12, 2019 at 4:59 PM Alexandru Pătrănescu drealecs@gmail.com
wrote:
Hi guys,
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.One problem that needs to be understood is that PHP is used by a lot of
users.
Because it's easy to pick up and you have fast feedback it probably have a
higher percentage of juniors than average.
I don't think "new developers might do it wrong" is a very compelling
argument. We shouldn't handcuff the language because some people might use
the flexibility improperly.
How language was 10 years ago it didn't helped them much in learning and
they did lot of mistakes. Some of those mistakes cost companies lots of
money and, in time, people got to the conclusion that PHP is bad.
This is a very important thing!, Yes you can write working great code in
PHP but it's very easy to write working bad code as well. And it's not
about you and me or the other persons chatting here, it's about the rest of
the world.
And I don't think we should take away the flexibility that makes PHP great
because some people don't use it correctly. "Billy can't code properly
unless the the application crashes whenever he doesn't initialize a
variable" isn't any more compelling when it's in the third person than it
was in the first person.
PHP improved on it's bad image in the later years but this needs to
continue. IMO, one thing that we need to also do is to make the language
image better.
With this in mind, I believe the "undefined variable" error will be a step
forward.
But it won't. People that won't a stricter language aren't going to start
using PHP because it suddenly throws more errors than it used to. As I
mentioned before, some non-PHP developers I knew find it appalling that
such a massive BC break was even being considered. As much as they don't
like the idea of uninitialized variables, the fact that they've been around
for 20 years and now there is talk of them making applications crash was
much bigger issue.
The way we improve PHPs image is we show why the things that make it unique
are actually good things, while adding NEW features to the language. No
matter how much we try to make PHP like Java, c#, python, etc., it isn't
going to entice those developers over to PHP when PHP doesn't offer them
anything different than what they already have.
It's not about if you don't consider it bad code and that apparently the
majority consider it good.
It's that if language wouldn't allow you to write that code it will
benefit the language image and the rest of the PHP comunity.Also, I would also like to remind of this:
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
I think some parts might have been violated multiple time in this thread.
I can take the hint. This will likely be my last post on the topic. I think
there are few others on this thread that can take up the fight from here on
out.
Regards,
AlexOn Thu, Sep 12, 2019 at 10:29 PM Chase Peeler chasepeeler@gmail.com
wrote: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
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
chasepeeler@gmail.com
On Thu, Sep 12, 2019 at 4:59 PM Alexandru Pătrănescu drealecs@gmail.com
wrote:Hi guys,
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.One problem that needs to be understood is that PHP is used by a lot of
users.
Because it's easy to pick up and you have fast feedback it probably have
a higher percentage of juniors than average.I don't think "new developers might do it wrong" is a very compelling
argument. We shouldn't handcuff the language because some people might use
the flexibility improperly.How language was 10 years ago it didn't helped them much in learning and
they did lot of mistakes. Some of those mistakes cost companies lots of
money and, in time, people got to the conclusion that PHP is bad.
This is a very important thing!, Yes you can write working great code in
PHP but it's very easy to write working bad code as well. And it's not
about you and me or the other persons chatting here, it's about the rest of
the world.And I don't think we should take away the flexibility that makes PHP great
because some people don't use it correctly. "Billy can't code properly
unless the the application crashes whenever he doesn't initialize a
variable" isn't any more compelling when it's in the third person than it
was in the first person.
I hate to see people taking PHP dynamic bug-friendly pattern as great
flexibility. Why would something be great and same time be bad?
Isn't that a contradiction?
PHP is great in flexibility for things like being dynamically typed, fast
to launch(major hosts always have it enabled), easier to understand but not
for allowing bugs that can cost huge money in the long run.
PHP is a very good friendly language when it comes to learning, yet the
worst language when it comes to ideology or roadmap.
Most companies only prefer PHP to make fast MVP, but as soon as that stage
passed, their HR would start searching for developers in other better
languages.
Check out stackoverflow and see how many buggy questions are asked daily.
PHP improved on it's bad image in the later years but this needs to
continue. IMO, one thing that we need to also do is to make the language
image better.
With this in mind, I believe the "undefined variable" error will be a
step forward.But it won't. People that won't a stricter language aren't going to start
using PHP because it suddenly throws more errors than it used to. As I
mentioned before, some non-PHP developers I knew find it appalling that
such a massive BC break was even being considered. As much as they don't
like the idea of uninitialized variables, the fact that they've been around
for 20 years and now there is talk of them making applications crash was
much bigger issue.The way we improve PHPs image is we show why the things that make it
unique are actually good things, while adding NEW features to the language.
No matter how much we try to make PHP like Java, c#, python, etc., it isn't
going to entice those developers over to PHP when PHP doesn't offer them
anything different than what they already have.It's not about if you don't consider it bad code and that apparently the
majority consider it good.
It's that if language wouldn't allow you to write that code it will
benefit the language image and the rest of the PHP comunity.Also, I would also like to remind of this:
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
I think some parts might have been violated multiple time in this thread.I can take the hint. This will likely be my last post on the topic. I
think there are few others on this thread that can take up the fight from
here on out.Regards,
AlexOn Thu, Sep 12, 2019 at 10:29 PM Chase Peeler chasepeeler@gmail.com
wrote: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
Or were you implying you want hitch-free, no-modification upgrade to PHP
8from 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
chasepeeler@gmail.com
On Fri, Sep 13, 2019 at 12:00 AM Alexandru Pătrănescu drealecs@gmail.com
wrote:
Also, I would also like to remind of this:
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
I think some parts might have been violated multiple time in this thread.
As was already pointed out in a different thread recently, the ones you
seem to refer to are guidelines - or rather 'hints'. They cannot be
'violated'. It doesn't mean it doesn't make sense to follow them - but
there's a reason they're only hints, and not rules.
Zeev
Hi Zeev,
I just reminded the rules so everyone remembers we have them for this
mailing list.
I actually was not referring to hints 1 and 2, even if I still believe they
are good hints to follow in order to have the discussion more productive
and respectful to everyone.
I was actually referring to rules 1 and 2 that I suspect might have been
violated.
Of course, the evaluation if they broke it or not would be first of all
(and best of all) done by each person individually.
I really hope everyone is self-evaluating every now and then.
Regards,
Alex
On Fri, Sep 13, 2019 at 12:00 AM Alexandru Pătrănescu drealecs@gmail.com
wrote:Also, I would also like to remind of this:
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
I think some parts might have been violated multiple time in this thread.As was already pointed out in a different thread recently, the ones you
seem to refer to are guidelines - or rather 'hints'. They cannot be
'violated'. It doesn't mean it doesn't make sense to follow them - but
there's a reason they're only hints, and not rules.Zeev
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
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
chasepeeler@gmail.com
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/releasesSo, to make some sort of a milestone with some of the versions -
either 8 or 9 or something.--
Peter Kokot--
--
Chase Peeler
chasepeeler@gmail.com
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/releasesSo, 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.
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