Re: [PHP-DEV] Changing fundamental language behaviors

This is only part of a thread. view whole thread
  106979
September 12, 2019 16:39 Andreas Heigl <andreas@heigl.org>
--KBQ22qBJZUetMbeu4mtLToJkiQ2Gns1BF
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey Zeev.

I'm not that deep into @internals and might not get the subtle subtext.
English is not my native tongue so I might phrase things in a way that
doesn't transport the whole meaning of my thoughts. But your Mail really
left me curious:

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

> I was really really hoping that we will avert having to dive into this = and
> instead go for the alternative solution that was proposed of changing > default php.ini error levels. But since the RFC went on to a vote - we=
> need > to make something clear. > > > > The RFC process was never, ever meant to handle fundamental changes to = the
> language. It was meant to deal predominantly with additions to the > language, as can be inferred from numerous parts in the phrasing. As I=
> mentioned in the past - it wasn't even intended to deal with simpler > deprecations, but it appears that the cat is out of the bag on this one= =2E
> 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 t= he
> 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 w= ith
> 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 wi= ll
> 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 behavio= r 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. =46rom what i see you tell us (@internals) "You're not allowed to do so, but I will not tell you who *is* allowed." So for me that raises two main questions: 1. Who then has the mandate to do so? 2. By what authority are you making this statement? I'm looking forward to your answers. Cheers Andreas
> > > > For areas like that - our options are either doing nothing, or providin= g
> opt-in mechanisms to cater to stricter-loving audiences. I'm all for t= he
> 2nd option, but there is no 3rd. > > > > Zeev
--=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --KBQ22qBJZUetMbeu4mtLToJkiQ2Gns1BF--
  107005
September 12, 2019 18:35 zeev@php.net (Zeev Suraski)
On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote:

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

> Most of these changes wouldn't have been problematic to you if the > language has prevented you from writing what we can now consider bad code, > so please allow the new PHP developer that newly start using PHP to not > follow that your path that will/might hunt him later in the future... > > There a notices, warning and errors to inform you that this shouldn't have > been the use case of this feature and you chose to ignore it and now, we > are simplifying things and making those your errors teach you how to write > proper codes in the future, you're objecting.. Why not just stay in PHP 7.x? > > Or were you implying you want hitch-free, no-modification upgrade to PHP 8 > from PHP 7.0? > If yes, follow the best practices and not suppress error notices. >
We're clearly talking past one another so I will be going back to work after this response. I am not saying anything about whether the warnings RFC should pass or fail, or if it makes my code good or bad. I responded explicitly to one idea about creating a LTS version that might somehow make it easier for RFCs like this one to be accepted because users could basically be encouraged to stay on the LTS version if the new major version introduces too many breaking changes, which I think is bad justification for creating a LTS version. I'm not sure how that equates to my code being good or bad or whether I am following someone else's recommended best practices, but that was never the point of discussion.
  107016
September 12, 2019 19:29 chasepeeler@gmail.com (Chase Peeler)
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 babker@gmail.com> > wrote: > > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> > > wrote: > > > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < > michael.babker@gmail.com> > >> wrote: > >> > >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> > >>> wrote: > >>> > >>> > Just a dumb idea, since there clearly is a majority in favor of the > >>> > change with these warnings and strictness and all that now... Why not > >>> > making something like an LTS PHP 7.x where all the legacy code would > >>> > work OK as long as practically possible and 8.x+ would be the future > >>> > of what the developers want and not what business wants? One who > won't > >>> > upgrade due to the BC breaks also won't need the new features anyway > >>> > very realistically. > >>> > > >>> > >>> Please don't tie the notion of LTS with the idea that a new major can > >>> break > >>> BC at will or create larger scale breaks because the previous major has > >>> extended support. Sooner or later that will end up back at the ++ idea > >>> and > >>> fragmentation encouraged by the language is a bad idea. > >>> > >> > >> Not sure you are really seeing the goal... > >> > >> Why is LTS not a good idea? > >> > > > > I'm not saying LTS is a bad idea. I'm saying using LTS to justify > > shipping larger scale BC breaks, such as the changes suggested in the > last > > couple of "contentious" RFCs in a major version because "hey, we have a > LTS > > version you can use that until you're ready to deal with the backlog of > BC > > breaks created" is a bad idea. > > > > > > For the record, I happen to agree with as these RFCs would have minimal > > impact on my day-to-day work, but having also been in the role of a > > maintainer of open source libraries and applications I also grasp why > these > > types of changes can be problematic to the ecosystem (both end users of > > those libraries and applications and the maintainers of them) and > wouldn't > > jump the gun to ship them without careful consideration. > > > > Most of these changes wouldn't have been problematic to you if the language > has prevented you from writing what we can now consider bad code, so please > allow the new PHP developer that newly start using PHP to not follow that > your path that will/might hunt him later in the future... > > Many of us don't consider it bad code. I've also always initialized
variables when it was required (and many times when it wasn't) even though I wasn't forced to do so. A lot of other people do as well. If it's so important to you, start a program to teach people how you think they should code.
> There a notices, warning and errors to inform you that this shouldn't have > been the use case of this feature and you chose to ignore it and now, we > are simplifying things and making those your errors teach you how to write > proper codes in the future, you're objecting..
As has been discussed before, notices are not the same as warnings and errors. Also, if those things are so wonderful, why can't you use them to catch the issues you are complaining you can't catch right now? Again, you are telling me there is something out there which will allow you to force yourself to write "good code" without forcing me to follow the same restrictions. Yet, you still feel it's necessary to not use those tools, and instead modify the entire language so that I am forced to follow what you deem best practices, even if I don't?
> Why not just stay in PHP 7.x? > > Because other features that I want to utilize will also be added in PHP 8.
Or were you implying you want hitch-free, no-modification upgrade to PHP 8
> from PHP 7.0? >
I never said that. Here we go again with the "I guess you are against all BC breaks" nonsense. If BC breaks are required to add new functionality, or, have a very minimal negative impact, then I don't have a problem with them. This is not one of those cases. It changes a fundamental aspect of the language, an aspect that many people actually like, and it doesn't add any new features to the language, nor is it needed to add any new features to the language.
> If yes, follow the best practices and not suppress error notices. > > Just My Opinion >
-- Chase Peeler chasepeeler@gmail.com
  107017
September 12, 2019 19:39 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 8: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 babker@gmail.com> >> wrote: >> >> > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> >> > wrote: >> > >> >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < >> michael.babker@gmail.com> >> >> wrote: >> >> >> >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> >> >>> wrote: >> >>> >> >>> > Just a dumb idea, since there clearly is a majority in favor of the >> >>> > change with these warnings and strictness and all that now... Why >> not >> >>> > making something like an LTS PHP 7.x where all the legacy code would >> >>> > work OK as long as practically possible and 8.x+ would be the future >> >>> > of what the developers want and not what business wants? One who >> won't >> >>> > upgrade due to the BC breaks also won't need the new features anyway >> >>> > very realistically. >> >>> > >> >>> >> >>> Please don't tie the notion of LTS with the idea that a new major can >> >>> break >> >>> BC at will or create larger scale breaks because the previous major >> has >> >>> extended support. Sooner or later that will end up back at the ++ >> idea >> >>> and >> >>> fragmentation encouraged by the language is a bad idea. >> >>> >> >> >> >> Not sure you are really seeing the goal... >> >> >> >> Why is LTS not a good idea? >> >> >> > >> > I'm not saying LTS is a bad idea. I'm saying using LTS to justify >> > shipping larger scale BC breaks, such as the changes suggested in the >> last >> > couple of "contentious" RFCs in a major version because "hey, we have a >> LTS >> > version you can use that until you're ready to deal with the backlog of >> BC >> > breaks created" is a bad idea. >> > >> >> >> > For the record, I happen to agree with as these RFCs would have minimal >> > impact on my day-to-day work, but having also been in the role of a >> > maintainer of open source libraries and applications I also grasp why >> these >> > types of changes can be problematic to the ecosystem (both end users of >> > those libraries and applications and the maintainers of them) and >> wouldn't >> > jump the gun to ship them without careful consideration. >> > >> >> Most of these changes wouldn't have been problematic to you if the >> language >> has prevented you from writing what we can now consider bad code, so >> please >> allow the new PHP developer that newly start using PHP to not follow that >> your path that will/might hunt him later in the future... >> >> > Many of us don't consider it bad code. I've also always initialized > variables when it was required (and many times when it wasn't) even though > I wasn't forced to do so. A lot of other people do as well. If it's so > important to you, start a program to teach people how you think they should > code. > > >> There a notices, warning and errors to inform you that this shouldn't have >> been the use case of this feature and you chose to ignore it and now, we >> are simplifying things and making those your errors teach you how to write >> proper codes in the future, you're objecting.. > > > As has been discussed before, notices are not the same as warnings and > errors. Also, if those things are so wonderful, why can't you use them to > catch the issues you are complaining you can't catch right now? Again, you > are telling me there is something out there which will allow you to force > yourself to write "good code" without forcing me to follow the same > restrictions. Yet, you still feel it's necessary to not use those tools, > and instead modify the entire language so that I am forced to follow what > you deem best practices, even if I don't? > > > >> Why not just stay in PHP 7.x? >> >> Because other features that I want to utilize will also be added in PHP > 8. > > 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?).
  107021
September 12, 2019 20:59 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
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 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 babker@gmail.com > > > > wrote: > > > > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.com> > > > wrote: > > > > > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < > > michael.babker@gmail.com> > > >> wrote: > > >> > > >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com> > > >>> wrote: > > >>> > > >>> > Just a dumb idea, since there clearly is a majority in favor of the > > >>> > change with these warnings and strictness and all that now... Why > not > > >>> > making something like an LTS PHP 7.x where all the legacy code > would > > >>> > work OK as long as practically possible and 8.x+ would be the > future > > >>> > of what the developers want and not what business wants? One who > > won't > > >>> > upgrade due to the BC breaks also won't need the new features > anyway > > >>> > very realistically. > > >>> > > > >>> > > >>> Please don't tie the notion of LTS with the idea that a new major can > > >>> break > > >>> BC at will or create larger scale breaks because the previous major > has > > >>> extended support. Sooner or later that will end up back at the ++ > idea > > >>> and > > >>> fragmentation encouraged by the language is a bad idea. > > >>> > > >> > > >> Not sure you are really seeing the goal... > > >> > > >> Why is LTS not a good idea? > > >> > > > > > > I'm not saying LTS is a bad idea. I'm saying using LTS to justify > > > shipping larger scale BC breaks, such as the changes suggested in the > > last > > > couple of "contentious" RFCs in a major version because "hey, we have a > > LTS > > > version you can use that until you're ready to deal with the backlog of > > BC > > > breaks created" is a bad idea. > > > > > > > > > > For the record, I happen to agree with as these RFCs would have minimal > > > impact on my day-to-day work, but having also been in the role of a > > > maintainer of open source libraries and applications I also grasp why > > these > > > types of changes can be problematic to the ecosystem (both end users of > > > those libraries and applications and the maintainers of them) and > > wouldn't > > > jump the gun to ship them without careful consideration. > > > > > > > Most of these changes wouldn't have been problematic to you if the > language > > has prevented you from writing what we can now consider bad code, so > please > > allow the new PHP developer that newly start using PHP to not follow that > > your path that will/might hunt him later in the future... > > > > > Many of us don't consider it bad code. I've also always initialized > variables when it was required (and many times when it wasn't) even though > I wasn't forced to do so. A lot of other people do as well. If it's so > important to you, start a program to teach people how you think they should > code. > > > > There a notices, warning and errors to inform you that this shouldn't > have > > been the use case of this feature and you chose to ignore it and now, we > > are simplifying things and making those your errors teach you how to > write > > proper codes in the future, you're objecting.. > > > As has been discussed before, notices are not the same as warnings and > errors. Also, if those things are so wonderful, why can't you use them to > catch the issues you are complaining you can't catch right now? Again, you > are telling me there is something out there which will allow you to force > yourself to write "good code" without forcing me to follow the same > restrictions. Yet, you still feel it's necessary to not use those tools, > and instead modify the entire language so that I am forced to follow what > you deem best practices, even if I don't? > > > > > Why not just stay in PHP 7.x? > > > > Because other features that I want to utilize will also be added in PHP > 8. > > Or were you implying you want hitch-free, no-modification upgrade to PHP 8 > > from PHP 7.0? > > > > I never said that. Here we go again with the "I guess you are against all > BC breaks" nonsense. If BC breaks are required to add new functionality, > or, have a very minimal negative impact, then I don't have a problem with > them. This is not one of those cases. It changes a fundamental aspect of > the language, an aspect that many people actually like, and it doesn't add > any new features to the language, nor is it needed to add any new features > to the language. > > > > If yes, follow the best practices and not suppress error notices. > > > > Just My Opinion > > > > > -- > Chase Peeler > chasepeeler@gmail.com >
  107022
September 12, 2019 21:15 chasepeeler@gmail.com (Chase Peeler)
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, > Alex > > > On 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 >> 8. >> >> Or were you implying you want hitch-free, no-modification upgrade to PHP 8 >> > from PHP 7.0? >> > >> >> I never said that. Here we go again with the "I guess you are against all >> BC breaks" nonsense. If BC breaks are required to add new functionality, >> or, have a very minimal negative impact, then I don't have a problem with >> them. This is not one of those cases. It changes a fundamental aspect of >> the language, an aspect that many people actually like, and it doesn't add >> any new features to the language, nor is it needed to add any new features >> to the language. >> >> >> > If yes, follow the best practices and not suppress error notices. >> > >> > Just My Opinion >> > >> >> >> -- >> Chase Peeler >> chasepeeler@gmail.com >> >
-- Chase Peeler chasepeeler@gmail.com
  107039
September 13, 2019 00:03 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019, 10:15 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> > > 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, >> Alex >> >> >> On 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 >>> 8. >>> >>> Or were you implying you want hitch-free, no-modification upgrade to PHP >>> 8 >>> > from PHP 7.0? >>> > >>> >>> I never said that. Here we go again with the "I guess you are against all >>> BC breaks" nonsense. If BC breaks are required to add new functionality, >>> or, have a very minimal negative impact, then I don't have a problem with >>> them. This is not one of those cases. It changes a fundamental aspect of >>> the language, an aspect that many people actually like, and it doesn't >>> add >>> any new features to the language, nor is it needed to add any new >>> features >>> to the language. >>> >>> >>> > If yes, follow the best practices and not suppress error notices. >>> > >>> > Just My Opinion >>> > >>> >>> >>> -- >>> Chase Peeler >>> chasepeeler@gmail.com >>> >> > > -- > Chase Peeler > chasepeeler@gmail.com >
  107026
September 12, 2019 21:51 zeev@php.net (Zeev Suraski)
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
  107038
September 12, 2019 23:56 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
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:51 AM Zeev Suraski <zeev@php.net> wrote:

> > > 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 > >
  107012
September 12, 2019 19:15 chasepeeler@gmail.com (Chase Peeler)
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 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
  107014
September 12, 2019 19:19 oludonsexy@gmail.com (Olumide Samson)
On Thu, Sep 12, 2019 at 8:15 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> > > On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson <oludonsexy@gmail.com> > wrote: > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 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 >
  107008
September 12, 2019 19:04 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 2:51 PM Peter Kokot <peterkokot@gmail.com> wrote:

> On Thu, 12 Sep 2019 at 20:35, Zeev Suraski <zeev@php.net> wrote: > > > > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote: > > > > > > > > > > > > You may be wondering, in that case, what processes do we have to deal > > > with > > > > such changes then? The answer is simple. We don't. We don't have > to > > > have > > > > them either - the fundamental language behaviors are here to stay. > > > > > > But we still need processes to define which are the "fundamental > > > language behaviours". And as change is the only constant in > > > software-development, these "fundamental language behaviours" might, > can > > > and probably should be changeable. I'm not saying they need to change, > > > but it has to be possible to change them. Otherwise we would still > > > program business-logic in C as that was Rasmus' fundamental idea IIRC > > > (Correct me if I'm wrong) > > > > > > > You're right. The thing is this - as I said, the RFC process was > designed > > to address additions to the language - as is implied in numerous places > > (both the part I quoted from the RFC itself, as well as elements in RFC > > template as well as the RFC howto). It was never meant to handle > > deprecations - mainly because we simply weren't doing much of that back > in > > the days where it was introduced. It was meant to resolve the issue at > > hand at the time (and in the years leading up to it) - which is a formal > > way to agree on which features make it in and which ones don't. > > Now, over the years (and more and more as of late) - it started being > used > > for deprecations. But these deprecations have become more and more > extreme > > recently in terms of their impact. Of course I do think deprecations > > should be allowed, like in any other language. I do think we need to > have > > a higher bar for them in general (both in terms of a clear benefits and > > required majority - as is implied in the Voting RFC) - but since we've > > grown used to using 2/3 for them - and given the pro-deprecation bias of > > the current composition of internals@ - I also realize it will be tough > to > > do. But when dealing with deprecation proposals that are likely to > effect > > a very sizable subset of our userbase and codebase, and deal with some of > > the most basic building blocks of the language - we simply can't start > > using the same process. We never have in the past (none of the > > deprecations we voted on since 2013 comes even remotely close to the > level > > of impact of the two proposals that have been put forward to a vote in > the > > recent couple of months, and the more recent one clearly far outdoes the > > prior one in terms of impact). > > > > Should we have 'woken up' many years ago when we started using the Voting > > RFC for deprecations it wasn't meant to handle? Probably. It would have > > been much easier to install a new mechanism. But it doesn't mean we > should > > repeat the same mistake, now that it begins to be used to deprecate > > mainstream language behaviors. > > > > In terms of telling one from the other - right now, I'm afraid it's a bit > > like some other things that fall into the category of 'you know it when > you > > see it'. I think few can deny that far-reaching effect of changing how > > variables behave in a language, whether they think it's a change for the > > better or for the worse. But I think it *may* be possible to formally > > define. These are just random thoughts at this point - but we could > have a > > set of apps/frameworks that we use as a testing bed to check the level of > > impact of a certain proposal. If that impact is above a certain > threshold > > - it will be considered fundamental. Of course, things like WordPress, > > Joomla and MediaWiki would have to be a part of that - not just modern > > frameworks. It's still not ideal since it doesn't account for the > majority > > of PHP code out there which isn't Open Source - but it may be a start. > > There may be other ways - such as letting folks run that analysis on > their > > own code behind the firewall and report results back. > > > > But there's also a simpler solution to this. This 'can of worms' as > Arvids > > called it, wouldn't have been opened had we agreed to focus on extending > > PHP instead of trying to replace it with something else. This is what > the > > RFC process was meant to facilitate. It still can, but for that, we need > > to change the dynamics from a zero-sum game to a goal of a win/win. > Yes, I > > realize that I'm sounding like a broken record. But call me naive - I'm > > still hoping that given it obviously can be done from a technical > > perspective (in a wide variety of ways too) - we can find the good will > to > > do it from a human perspective. > > > > Zeev > > > > > > > > > Just a dumb idea, since there clearly is a majority in favor of the > change with these warnings and strictness and all that now... Why not > making something like an LTS PHP 7.x where all the legacy code would > work OK as long as practically possible and 8.x+ would be the future > of what the developers want and not what business wants? One who won't > upgrade due to the BC breaks also won't need the new features anyway > very realistically. > > Someone that has a lot of uninitialized variables could definitely take
advantage of features like enums and union types (just to name a few). If there were actually new, useful features that were dependent on such a change, then I'd be much more open to the idea, if not outright in favor of it. However, there aren't any new and useful features that are dependent on the errors being thrown for uninitialized variables.
> Microsoft, Zend, and Red Hat have been showing that this is actually > possible. How smart this is for the PHP progress is another story, but > for the business it might be good to think about this also I guess: > https://github.com/microsoft/php-src/releases > > So, to make some sort of a milestone with some of the versions - > either 8 or 9 or something. > > > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  107076
September 13, 2019 12:19 remi@php.net (Remi Collet)
Le 12/09/2019 à 20:51, Peter Kokot a écrit :

> Just a dumb idea, since there clearly is a majority in favor of the > change with these warnings and strictness and all that now... Why not > making something like an LTS PHP 7.x where all the legacy code would > work OK as long as practically possible and 8.x+ would be the future > of what the developers want and not what business wants? One who won't > upgrade due to the BC breaks also won't need the new features anyway > very realistically. > > Microsoft, Zend, and Red Hat have been showing that this is actually > possible. How smart this is for the PHP progress is another story, but > for the business it might be good to think about this also I guess: > https://github.com/microsoft/php-src/releases > > So, to make some sort of a milestone with some of the versions - > either 8 or 9 or something.
This is chicken and eggs problem "Maintained because used" or "used because maintained" ? PHP 7 was a very good version, with good BC, and speed of adoption is quite good. But some users still old 5.x From download of my repo [1] In January, ~35% for 5.6 In August, down to ~28% IMHO, more BC breaks will mean more time to adapt code and more slow adoption by users. So Yes, we'll need a longer support time for 7.4, as we have extended support for 5.6 by 1 year). Perhaps more will be needed for 7.4. But yes, we are allowed to change things and dream of a perfect language, like Perl 6... Remi [1] this are only numbers... from about 5k RPM download per day, and probably artificially bigger for EOL versions, because I'm the only repo to provide them.
  107009
September 12, 2019 19:06 chasepeeler@gmail.com (Chase Peeler)
On Thu, Sep 12, 2019 at 2:35 PM Zeev Suraski <zeev@php.net> wrote:

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