Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 10:28 PM Matthew Brown wrote: > Javascript has treated undefined variables as a catchable exceptions since > (I think?) forever. Perl is the only other language I know that allows them. > That isn't the point (I alluded to the fact that JS dealt with something *similar* but not quite the same in my first mention of it). The point is that when they wanted to make behavior around variables strict*er* than what it was originally, they didn't simply change it - they added an opt-in strict mode. I've written code in a lot of different languages. Many of those languages > (most notably Standard ML) forced me to think about how exactly data flowed > through my program. PHP, on the other hand, doesn't demand anything like as > much work. This means its developers often don't improve much either, which > ultimately this harms the language's reputation as former PHP developers > discover their bad habits don't translate well to other languages. > > With this change we can make it harder for people to write bad code, which > I think will result in existing PHP users becoming better developers. > With this change we're taking away from people - including very informed developers - the ability to use it as intended (one form of it that is). There's a reason there's a wide selection of languages available, and that different people have different language preferences. Personally, I can't stand ML - and I find myself a lot more productive in other languages. But I'm not going to campaign to change ML into something different because it doesn't fit my programming/thinking style. Granted - PHP is orders of magnitude more popular and widely used than ML, and we need to figure out ways to make this huge audience content - including many who aren't happy with its behavior (whether it's because they made an uninformed decision choosing it, or because it wasn't their choice at all, or because they actually do like the language and would be happy to use it if only it had X, Y and Z). But it shouldn't be at the expense of others. Exactly like Perl and JS did it when they decided to offer a stricter execution model. Zeev
Re: [PHP-DEV] Proposal for a RFC
Hey Benjamin, On Thu, Aug 29, 2019, 05:09 Benjamin Eberlei wrote: > > > On Sun, May 5, 2019 at 5:08 PM Nicolas Grekas > wrote: > >> Le sam. 4 mai 2019 à 18:37, Marco Pivetta a écrit : >> >> > Hi Steven, >> > >> > As it currently stands, the array cast is the only operation capable of >> > exposing object state without triggering any kind of access guards: it >> is >> > very much required for anything that works with reflection and typed >> > properties, and possibly the only operation in PHP that operates on >> state >> > without some contraption intercepting its execution. >> > >> > It is also necessary to distinguish dynamic properties from declared >> object >> > state. >> > >> > For comparison, all of the following have side-effects due to the >> > complexity of the language: >> > >> > * isset() >> > * unset() >> > * property read >> > * property write >> > * ReflectionProperty#getValue() >> > * ReflectionProperty#setValue() >> > >> > Overall, this is problematic, and introduces more magic that I'd gladly >> > avoid, in an endpoint used to work around all the engine magic (the only >> > stable one so far). >> > >> > From my end, this sounds like a bad idea, because it removes one of the >> > very very few referentially transparent guarantees (if not the only one, >> > when dealing with objects) from the language. >> > >> > Greets, >> > >> > Marco >> > >> >> I want to weight in with what Marco expressed. I have the very same >> concerns and they are major ones for many use cases. Mine is VarDumper. >> >> Please don't do this the way it is described. >> > > Because Steve asked for wiki access to work on an RFC for his proposal, I > went back and re-read and just wanted to come in his support as I think it > would be a great addition to the existing __magic functionality, > > I want to add a few more arguments why __toArray() should be added > regardless of the objections from Marco & Nicolas: > > 1. PHP already has __debugInfo() which affects the behavior of var_dump() > allowing users to control what gets exposed to it in a debugging context. > This is new magic method would affect Symfony's VarDumper+ VarCloner in a > similar consistent way that gives class owners back control of what gets > exposed. One primary benefit of OOP is encapsulation and guarding against > access of internal state from the outside, so it is questionable anyways > why an idiomatic and simple to use syntax like (array) $object would expose > internal state and a developer would have no means of preventing that. > __debugInfo is already arguably added complexity and debugging time for those looking at a dump result and not understanding it. From my PoV, I'd love to also see __debugInfo gone, since it only ever caused me to lose hair. > 2. Adding __toArray would not constitute a backwards compatibility break, > because all existing code does not implement __toArray and would keep the > same exact behavior. > It would break any code relying on current `(array)` semantics against the general `object` type. Can certainly propose it for 8.x, and then we go on a hunt for `(array)` casts, and disallowing them explicitly (cs, static analysis). > 3. You can't argue against the concept of magic methods overall by citing > your own use case that is objectively an extremely magic use of the > existing behavior of (array) $object itself. I can see a very good case to > change (array) $object to return only public properties as part of the > general push to cleanup inconsistent behavior in PHP 8. As Nikita > mentioned, it might make sense to add a function that is specifically > designed for your both use-cases instead and that would honestly make this > part of the language cleaner in the end and we can get rid of this * > protected and nullbyte private variable returning behavior once and for all. > It's fine to break this for 8.x, but I think 7.4 already has an added API for this? Can't remember the name, but something about unmangled vars. > 4. ReflectionProperty::getValue() does not trigger a guard clause if you > call setAccessible(true) first, so I don't think the objection that this is > the only way to access private data is true here. Correct me if I forgot an > edge case that prevents this. > Guards are triggered for unset properties, even with reflection. > 5. Arguments of API design that toSomethingString() is somehow "better" > than using __toString() and therefore the addition of __toArray() is bad > pit one paradigm (explicit OOP vs magic methods) and should be avoided in > an RFC discussion. We are also not discussing to remove functions in PHP > because we now have classes and methods and this falls into the same > category. Its a subject design decision and shouldn't influence the > expansion of an existing feature/paradigm that one doesn't use themselves. > I'd say that the paradigm is at the core of the discussion: magic calls are some of the worst traps in the language, leading to monstrous
Re: [PHP-DEV] Re: [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 10:26 PM Nikita Popov wrote: > On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov > wrote: > > Reading this discussion has been disappointing and somewhat disillusioning. > I can understand and appreciate the concern for legacy code. But seeing the > use of undefined variables espoused as a legitimate programming style, that > just makes me sad. > Nikita, It's really awkward that anybody would be under the illusion that the way the language always behaved, consistently and well-documented pretty much from the its inception, is somehow a bug that everybody agrees on that's just waiting for someone to come over and fix it. Do you really think that if there was widespread consensus that this wasn't a legitimate programming style, we'd have to wait for 20 years for folks to propose to change/remove it? This isn't short tags - this is fundamental language behavior, that indeed isn't even documented anywhere as a 'bad thing you must avoid'. There are commonly used code templates that rely on it, and do it in a way many would find perfectly reasonable. Many do, and always did consider it as a legitimate programming style. Many others do not - which is why we added capabilities ages ago (from the get go, for all practical purposes) that allow users to employ a much stricter programming style by enabling notices. We never, ever, at any point, considered this behavior to be 'legacy'. It's a language feature, that you can choose whether you want to use or not (and perhaps we can get better at that). The fact that PHP isn't supposed to be a strict language is repeatedly confused with exclusive concern for 'legacy code' as of late. Yes, the complete disregard for backwards compatibility that appears to be the most widely accepted POV on internals is disconcerting - but much more importantly - just because one doesn't like a certain fundamental part of the language, doesn't make the use of it 'legacy'. If anything, it perhaps means that said person who chose the language made the wrong choice (there are plenty of other choices to choose from), and they're now campaigning to change it to fit the image of what they think it *should be* that they have in mind. With that said - I think it does make sense to try and come up with ways to cater to those who prefer a stricter language, and in this particular case - something that's a bit more aggressive than notices. But if there's something sad about this, it's the insistence to always frame the discussion as a zero sum game - instead of trying to find solutions that cater to a wider audiences. It's time to accept that the composition of PHP users is a lot wider than what's represented on internals, and it's certainly not everyone's opinion that the current language is in dire need of being rescued. PHP can be improved for those who find it lacking, without harming those who are in fact happy with the way it currently is. We should start looking for such solutions, instead of each just trying to 'win for their own camp', putting things to a vote hoping to subjugate the other. Zeev
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
> On 28 Aug 2019, at 23:04, Chase Peeler wrote: > > On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen wrote: > >> Hi >> >> Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler >> : >>> You going to come and fix the issues? It's an internal application and >>> most of those messages are coming from legacy areas of the code which are >>> mainly "it works, so leave it alone" things. Instead of going back and >>> spending time trying to fix those boondoggles, we invest the time of our >>> developers (there are 2 others besides myself) into building new features >>> that help our business grow. Time permitting, we try and update some of >> the >>> legacy areas, but, we usually find it's a better investment to just >> rebuild >>> them at that point. >>> >>> Bottom line is that we live with the not-so-good stuff so that we can >> focus >>> on adding new great stuff. The not-so-good stuff isn't holding us back, >> and >>> trying to fix things like undeclared variables would have absolutely ZERO >>> positive effect on our business, which uses this application every day. >> If >>> I went to our executive team and said "Can we delay that new scheduling >>> system that will really help our business so I can go back and update >> code >>> to get rid of these undeclared variable notices?" I'd get laughed at! >>> >>> Like I've said before - can we please stop pretending we understand >>> everyone else's situation? Maybe my situation is unique. My gut tells me >> it >>> might be unique among people on this list, but, that it's actually pretty >>> common among the myriad of developers out there which never get involved >> in >>> these discussions. >> >> I'm sorry, but like Mark Randall has already pointed out then this is >> a classic example of technical depth. At one point you must choose, >> "Do I want to upgrade to the latest version of PHP or do I want to fix >> the issues which is caused by the technical depth in my stack?". > > > I don't get to make that choice, though. The executives do. > I thought you said you were the tech lead? Part of building an application is maintaining it. And honestly, your claim about “it’s technical debt that is no longer growing” is incorrect. Like financial debt, technical debt will accrue “interest” - in this case, it’s going to prevent you from upgrading to a newer release of PHP. Believe me I understand your situation, in terms of code very well. This RFC, the short open tags one, and probably some more before 8.0 is frozen will all affect an active client project I’m tech lead for. In every case, I’m still for the change: because making the change means one less type of sloppy-but-“working” code I’m going to see and have to task someone to fix in the future. If you can’t currently schedule some percentage of development time to maintaining/fixing existing code, (you *did* say you’re the tech lead, right?) this RFC makes your job easier then: you have an external control factor that your executives (who apparently make technical decisions?) cannot argue against, and cannot deny. > >> I get >> it, writing new code is always more fun, it really is, > > > It's not about what is more fun. It's about what is necessary for our > company to grow, move forward, and survive. What good is fixing old code if > our company withers away while we do it since we aren't supporting them > with the new things the need to move forward? We aren't building things on > top of that old code, so, the new things we build aren't accruing > additional technical debt as a result of the existing technical debt. > Well presumably a working, secure application/website is necessary for the company to just survive, let alone grow. > I have >> previously worked with companies with that same attitude that "we'll >> fix it later", but at one point that becomes such a burden and if your >> management doesn't believe in putting in resources to actual >> maintenance of your infrastructure, then I'm sorry but it does not >> sound like a healthy place to be (no offense meant). >> >> That's not exactly our attitude. If something is really broken, we fix it. > We are not focusing our limited resources on updating things that currently > work just because we don't like how they were built. Most of it was done > 10-15 years ago, and, even if we had the resources to update it, we'd be > better off just rebuilding it altogether. Let me focus on the technical > debt that has high interest, instead of the debt that doesn't really impact > anything, like undeclared variables. Exactly how many instances of undeclared variables do you have? This talks about PHP8, so its expected 7.4 due late November this year will be the last version that doesn’t error on your code. 7.4 will have 2 years of full support and a further year of security support. Can you *really* not find the time to fix undeclared variables in the next 39 months? > >> Right now your argument is merely trying to
Re: [PHP-DEV] Proposal for a RFC
On Sun, May 5, 2019 at 5:08 PM Nicolas Grekas wrote: > Le sam. 4 mai 2019 à 18:37, Marco Pivetta a écrit : > > > Hi Steven, > > > > As it currently stands, the array cast is the only operation capable of > > exposing object state without triggering any kind of access guards: it is > > very much required for anything that works with reflection and typed > > properties, and possibly the only operation in PHP that operates on state > > without some contraption intercepting its execution. > > > > It is also necessary to distinguish dynamic properties from declared > object > > state. > > > > For comparison, all of the following have side-effects due to the > > complexity of the language: > > > > * isset() > > * unset() > > * property read > > * property write > > * ReflectionProperty#getValue() > > * ReflectionProperty#setValue() > > > > Overall, this is problematic, and introduces more magic that I'd gladly > > avoid, in an endpoint used to work around all the engine magic (the only > > stable one so far). > > > > From my end, this sounds like a bad idea, because it removes one of the > > very very few referentially transparent guarantees (if not the only one, > > when dealing with objects) from the language. > > > > Greets, > > > > Marco > > > > I want to weight in with what Marco expressed. I have the very same > concerns and they are major ones for many use cases. Mine is VarDumper. > > Please don't do this the way it is described. > Because Steve asked for wiki access to work on an RFC for his proposal, I went back and re-read and just wanted to come in his support as I think it would be a great addition to the existing __magic functionality, I want to add a few more arguments why __toArray() should be added regardless of the objections from Marco & Nicolas: 1. PHP already has __debugInfo() which affects the behavior of var_dump() allowing users to control what gets exposed to it in a debugging context. This is new magic method would affect Symfony's VarDumper+ VarCloner in a similar consistent way that gives class owners back control of what gets exposed. One primary benefit of OOP is encapsulation and guarding against access of internal state from the outside, so it is questionable anyways why an idiomatic and simple to use syntax like (array) $object would expose internal state and a developer would have no means of preventing that. 2. Adding __toArray would not constitute a backwards compatibility break, because all existing code does not implement __toArray and would keep the same exact behavior. 3. You can't argue against the concept of magic methods overall by citing your own use case that is objectively an extremely magic use of the existing behavior of (array) $object itself. I can see a very good case to change (array) $object to return only public properties as part of the general push to cleanup inconsistent behavior in PHP 8. As Nikita mentioned, it might make sense to add a function that is specifically designed for your both use-cases instead and that would honestly make this part of the language cleaner in the end and we can get rid of this * protected and nullbyte private variable returning behavior once and for all. 4. ReflectionProperty::getValue() does not trigger a guard clause if you call setAccessible(true) first, so I don't think the objection that this is the only way to access private data is true here. Correct me if I forgot an edge case that prevents this. 5. Arguments of API design that toSomethingString() is somehow "better" than using __toString() and therefore the addition of __toArray() is bad pit one paradigm (explicit OOP vs magic methods) and should be avoided in an RFC discussion. We are also not discussing to remove functions in PHP because we now have classes and methods and this falls into the same category. Its a subject design decision and shouldn't influence the expansion of an existing feature/paradigm that one doesn't use themselves. > Nicolas >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Thu, Aug 29, 2019, 12:33 AM Stanislav Malyshev
wrote:
> Hi!
>
> On 8/28/19 4:23 PM, Matthew Brown wrote:
> > $foo++ becoming 1 when $foo is undefined is not intuitive to me.
>
> I guess we have different intuition.
>
> > To take a very trivial example, that behaviour causes “for ($i = 0;
> > $i < 10; $I++) {}” to loop indefinitely.
> This is rather shallow issue, which any modern IDE would highlight for
> you in about 0.5 seconds. No need to change the language for that.
> Frankly, I have hard time remembering when any of such typos ever get
> past IDE check since I started using IDEs.
> And, of course, it's completely obvious issue - you could as well forget
> to write $i++ at all, or write $j++ and have $j defined somewhere...
> there's a lot of artificial scenarios one could think of. No reason to
> change rules of the whole language because of it.
>
Can you point me to an IDE that runs on the server?
I think you are mixing static analysis error with dynamic runtime analysis.
IDE can't point to an error it doesn't know about(which I didn't code using
IDE but use notepad, where I didn't run full test before publishing to
production).
I don't think it makes sense to allow the language be a home of "anything
goes, no innovation".
A language without specification.
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi!
On 8/28/19 4:23 PM, Matthew Brown wrote:
> $foo++ becoming 1 when $foo is undefined is not intuitive to me.
I guess we have different intuition.
> To take a very trivial example, that behaviour causes “for ($i = 0;
> $i < 10; $I++) {}” to loop indefinitely.
This is rather shallow issue, which any modern IDE would highlight for
you in about 0.5 seconds. No need to change the language for that.
Frankly, I have hard time remembering when any of such typos ever get
past IDE check since I started using IDEs.
And, of course, it's completely obvious issue - you could as well forget
to write $i++ at all, or write $j++ and have $j defined somewhere...
there's a lot of artificial scenarios one could think of. No reason to
change rules of the whole language because of it.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
$foo++ becoming 1 when $foo is undefined is not intuitive to me.
To take a very trivial example, that behaviour causes “for ($i = 0; $i < 10;
$I++) {}” to loop indefinitely.
> On Aug 28, 2019, at 6:52 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> This is where I think PHP may have broken us a little.
>
> I think it's in no way "broken" to be able to easily match expectations,
> like $foo++ always do what you meant without clunky boilerplate.
> Also, if you think PHP is the only language I program in daily (and I
> mean every day, except some weekends and vacations maybe) you're wrong
> :) I have something to compare to, so what I say some things are easier
> in PHP that's because I actually compared.
>
>> I just asked a few non-PHP developers here what they expect "(function
>> () { $a++; })()" to do, and they agreed it would be some sort of error.
>> Got the same answer for "(function () { $a->bar = 5; })() ".
>
> I see absolutely no reason for it. Maybe if you're a Java programmer who
> never saw non-statically-typed non-B language - but that's not a
> virtue we should be striving to emulate. If we have a tool that already
> does things better and some people don't even know such tools are
> possible, we should educate them, not break our tools so it would be
> more comfortable fit to their experience.
>
>> Indeed, anyone who's used another C-like language (JS, TS, Java, C# etc)
>> is used to these things being errors, so it can be disorientating to see
>
> I don't think having things just work instead of usual boilerplate that
> you have to declare everything upfront and repeat even obvious things
> numerous times is "disorienting" in any way. If you check how languages
> that are alive evolve (like Java or C++, C is mostly fossilized these
> days), even strict ones, you see they support more and more intuitive
> approaches - like auto variables for example - which make things easier.
> Because human should spend time thinking, not figuring out how to
> satisfy a dumb compiler. That's the direction we should be moving to.
> Not adding more errors and boilerplate in clear cases like $foo++.
>
> --
> Stas Malyshev
> smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi!
> This is where I think PHP may have broken us a little.
I think it's in no way "broken" to be able to easily match expectations,
like $foo++ always do what you meant without clunky boilerplate.
Also, if you think PHP is the only language I program in daily (and I
mean every day, except some weekends and vacations maybe) you're wrong
:) I have something to compare to, so what I say some things are easier
in PHP that's because I actually compared.
> I just asked a few non-PHP developers here what they expect "(function
> () { $a++; })()" to do, and they agreed it would be some sort of error.
> Got the same answer for "(function () { $a->bar = 5; })() ".
I see absolutely no reason for it. Maybe if you're a Java programmer who
never saw non-statically-typed non-B language - but that's not a
virtue we should be striving to emulate. If we have a tool that already
does things better and some people don't even know such tools are
possible, we should educate them, not break our tools so it would be
more comfortable fit to their experience.
> Indeed, anyone who's used another C-like language (JS, TS, Java, C# etc)
> is used to these things being errors, so it can be disorientating to see
I don't think having things just work instead of usual boilerplate that
you have to declare everything upfront and repeat even obvious things
numerous times is "disorienting" in any way. If you check how languages
that are alive evolve (like Java or C++, C is mostly fossilized these
days), even strict ones, you see they support more and more intuitive
approaches - like auto variables for example - which make things easier.
Because human should spend time thinking, not figuring out how to
satisfy a dumb compiler. That's the direction we should be moving to.
Not adding more errors and boilerplate in clear cases like $foo++.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
This is where I think PHP may have broken us a little.
I just asked a few non-PHP developers here what they expect "(function () {
$a++; })()" to do, and they agreed it would be some sort of error. Got the
same answer for "(function () { $a->bar = 5; })() ".
Indeed, anyone who's used another C-like language (JS, TS, Java, C# etc) is
used to these things being errors, so it can be disorientating to see them
treated as anything else by PHP (it was disorientating for me, at least).
On Wed, 28 Aug 2019 at 18:06, Stanislav Malyshev
wrote:
> Hi!
>
> > If we want PHP to be as easy as possible then $nullref->bar(),
> > $foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions
> > either - they can just be notices.
>
> I don't see how it follows. Calling unknown method does not have natural
> default - if I tell you "would you please do abracadabra" you can't just
> do something random and consider it done - you should tell me "what do
> you mean by that? Please explain what you want me to do".
> However, if I tell you "here's an apple, add it to your pocket", then
> there's a natural way of knowing how many apples is in your pocket for
> every state of your pocket before - if your pocket was empty, it now has
> one apple, if it had apples before, now it has one more. I don't need to
> explain you what to do when your pocket is empty and when it's not
> separately - you can guess intuitively what should happen in each case
> and you'd be 100% right always.
>
> That's the natural difference between $foo++ and foo() - in the former
> case, you know what should happen in any case (including when $foo is
> initialized to a non-numeric value - *then* you error out), in the
> latter, if foo() is not defined, there's no natural way to go but to
> error out. There's a crucial difference here because variables are
> containers, not actors. Dealing with an empty container has natural
> semantics (in some cases at least), dealing with non-existing actor does
> not.
> --
> Stas Malyshev
> smalys...@gmail.com
>
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi! > If we want PHP to be as easy as possible then $nullref->bar(), > $foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions > either - they can just be notices. I don't see how it follows. Calling unknown method does not have natural default - if I tell you "would you please do abracadabra" you can't just do something random and consider it done - you should tell me "what do you mean by that? Please explain what you want me to do". However, if I tell you "here's an apple, add it to your pocket", then there's a natural way of knowing how many apples is in your pocket for every state of your pocket before - if your pocket was empty, it now has one apple, if it had apples before, now it has one more. I don't need to explain you what to do when your pocket is empty and when it's not separately - you can guess intuitively what should happen in each case and you'd be 100% right always. That's the natural difference between $foo++ and foo() - in the former case, you know what should happen in any case (including when $foo is initialized to a non-numeric value - *then* you error out), in the latter, if foo() is not defined, there's no natural way to go but to error out. There's a crucial difference here because variables are containers, not actors. Dealing with an empty container has natural semantics (in some cases at least), dealing with non-existing actor does not. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
> If we want PHP to be as easy as possible then $nullref->bar(),
> $foo->someUndefined(),
> new UndefinedClass etc shouldn’t be exceptions either - they can just be
> notices.
That's very different. Note that this code doesn't even generate a notice:
$x = null;
var_dump($x+1);
I'm joining the thread to point out another way to avoid the notice in hopes
that
this way doesn't get deprecated or somesuch:
$temp =& $never_defined; // No notice :)
$temp++; // Happily becomes 1 if $never_defined wasn't defined
unset($temp); // so we don't unintentionally make more changes with $temp later
Our code predates "??" and we use the above boilerplate in many, many places,
but
it isn't boilerplate enough to easily search and replace.
- Todd
> On Aug 28, 2019, at 4:01 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> Javascript has treated undefined variables as a catchable exceptions since
>> (I think?) forever.
>
> Which seems to be why I open a random Javascript file in our codebase
> and see this:
>
> var wikibase = wikibase || {};
> wikibase.queryService = wikibase.queryService || {};
> wikibase.queryService.ui = wikibase.queryService.ui || {};
> wikibase.queryService.ui.toolbar = wikibase.queryService.toolbar || {};
>
> wikibase.queryService.ui.toolbar.Actionbar = ...
>
> (not my code but I've seen it a lot)
> IMHO, this is language getting in a way and people writing boilerplate
> to avoid "service" that is not actually needed.
>
>> much work. This means its developers often don't improve much either, which
>
> I don't think PHP should be a language that "builds character" by
> forcing people to do more work than it's necessary for them, in order
> for them to "improve". I think it should be as easy as possible, and if
> somebody wants to learn how the bits move, one can always pick up a good
> book or go to a Coursera course, etc.
>
> --
> Stas Malyshev
> smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
If we want PHP to be as easy as possible then $nullref->bar(),
$foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions either -
they can just be notices.
> On Aug 28, 2019, at 4:01 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> Javascript has treated undefined variables as a catchable exceptions since
>> (I think?) forever.
>
> Which seems to be why I open a random Javascript file in our codebase
> and see this:
>
> var wikibase = wikibase || {};
> wikibase.queryService = wikibase.queryService || {};
> wikibase.queryService.ui = wikibase.queryService.ui || {};
> wikibase.queryService.ui.toolbar = wikibase.queryService.toolbar || {};
>
> wikibase.queryService.ui.toolbar.Actionbar = ...
>
> (not my code but I've seen it a lot)
> IMHO, this is language getting in a way and people writing boilerplate
> to avoid "service" that is not actually needed.
>
>> much work. This means its developers often don't improve much either, which
>
> I don't think PHP should be a language that "builds character" by
> forcing people to do more work than it's necessary for them, in order
> for them to "improve". I think it should be as easy as possible, and if
> somebody wants to learn how the bits move, one can always pick up a good
> book or go to a Coursera course, etc.
>
> --
> Stas Malyshev
> smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi! > Because it's explicit, and incrementing null is mathematically > unintuitive. After all, null does not exist anywhere in the set of It is well-established in programming that default value for numeric types is 0 (many Java IDEs, for example, will explicitly tell you if you initialize a numeric value to 0 that it's not necessary). It is also well established that natural conversion of null to numeric is 0. I don't see anything non-intuitive here. Even if you have no idea about programming at all, how do you start counting? You had nothing, than one, then two, etc. You don't count like "did I start counting? No? Then nothing. Did I start again? Oh, now I did, then it's one. Did I start again? Oh yes, I did already, so it's two.". Nobody counts like that. It's completely non-intuitive and that's why I called it a clunker. It's working around language trying to be "helpful" but ending up forcing extra work because it looked "cleaner" to somebody. > ?? Let's you go "I know this index may not exist, if it doesn't, use 0 > instead". No funky type coercions that are in no way apparent from > looking at the code. Everybody - I mean literally everybody, I have not seen any exceptions I can think of over my 30+-year career in software - wants to start from 0 if counting wasn't started yet. If they didn't, there would be explicit initialization beforehand, you don't just suddenly forget you want to start counting from 100, it's an unusual thing that you remember. Starting from 0 you don't have to remember because everything starts from 0. There's no case for it being anything else. There's no need to make it explicit - nobody would imagine you mean anything but that, because nobody ever does anything but that ever. Spelling it out is just wasting time for the sake of being "strict". No added value. > To use the analogy someone posted elsewhere... the training wheels are > coming off. Time to be responsible and type those few extra characters > to be clear on your intent. Removing training wheels doesn't mean putting a boot on instead. No need to make something harder just for the sake of forcing people to explicitly acknowledge the situation that is obvious for everybody anyway. There can be only one intended way this construct could work, and it should work this way without spelling it out explicitly. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: strongholdmedia
I am already a minor contributor on github (with the same ID). My immediate scope would be documentation fixes / updates, but I also wish to keep fixing bugs for the time being. No write access for the tree is okay to begin with, I guess I may keep the GitHub flow for PRs currently. Commenting/asking on bugs is nice though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28/08/2019 20:48, Stanislav Malyshev wrote: Sure, that works. But I don't see any way this clunker is better than $counts[$key]++ Because it's explicit, and incrementing null is mathematically unintuitive. After all, null does not exist anywhere in the set of natural numbers, so Roman etymology aside, adding 1 to it shouldn't magic it into a completely different type without some explicit cast. ?? Let's you go "I know this index may not exist, if it doesn't, use 0 instead". No funky type coercions that are in no way apparent from looking at the code. To use the analogy someone posted elsewhere... the training wheels are coming off. Time to be responsible and type those few extra characters to be clear on your intent. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi!
> Javascript has treated undefined variables as a catchable exceptions since
> (I think?) forever.
Which seems to be why I open a random Javascript file in our codebase
and see this:
var wikibase = wikibase || {};
wikibase.queryService = wikibase.queryService || {};
wikibase.queryService.ui = wikibase.queryService.ui || {};
wikibase.queryService.ui.toolbar = wikibase.queryService.toolbar || {};
wikibase.queryService.ui.toolbar.Actionbar = ...
(not my code but I've seen it a lot)
IMHO, this is language getting in a way and people writing boilerplate
to avoid "service" that is not actually needed.
> much work. This means its developers often don't improve much either, which
I don't think PHP should be a language that "builds character" by
forcing people to do more work than it's necessary for them, in order
for them to "improve". I think it should be as easy as possible, and if
somebody wants to learn how the bits move, one can always pick up a good
book or go to a Coursera course, etc.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi! > Besides, we have tools available for years now to make this behaviour > more defined: > > $counts[$key] = ($counts[$key] ?? 0) + 1; Sure, that works. But I don't see any way this clunker is better than $counts[$key]++ -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi! > For example, I just recently fixed a bug, that did this: `$array['key'] += > $cost` - the array key was not initialised. Well, turned out that in this > case instead of null, it actually grabbed some garbage number out of memory This would be a serious engine bug that you should submit to bugs.php.net (probably as security issue, because "garbage from memory" can contain sensitive data, and such bug could leak things like SSL private keys outside). This however should not be part of this discussion since this is engine bug, not expected behavior. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi! > Don't build your business on a foundation of eggshells and then complain > when something comes along that makes those eggshells crumble. I think PHP has historically been much less "bondage and discipline" language, strictly enforcing a particular programming paradigm, than others (e.g. Java). I consider it a good thing. Scratch that, I consider it an excellent thing, responsible for the significant part of why PHP became so popular. I understand that some people like PHP to be much more B and enforce strictly whatever they consider (often entirely justified) the right way to do things. I don't think it's a place of a generic language to do that. We have IDEs, we have analyzers, we have other tools that allow to enforce things. For example, I don't think I had a "variable name typo" error in live code for years - because IDEs and tests catch those early. Do I need language to help me with that? Not really, I'm covered already. Do I want the language become more rigid and my quick-n-dirty PHP code snippets that I write almost every day become harder to write because I need to jump over the hoops that eventually will help "foundation of my business" built on that screen scraping script I've whipped up on a lunch break? Not at the least. Now, I recognize it's a valid position to want more strictness, especially if most of the code you deal with is "foundation of your business" type. I would just like to remind it's not the only position and that there's good in PHP being not as strict as, say, Java (I am not saying this proposal would make it that, but it's certainly looks like a step in that direction). -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi, On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: > > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefined variable" only generating a > notice is really quite mind-boggling. > As a user dealing with a big legacy code-base that's still being in heavy use and active development, while I appreciate this RFC in general, let me please voice my concerns about promoting "Undefined index: %s" from E_NOTICE to E_WARNING without also doing other changes. The point is that in many cases, PHP still tends to just emit an E_WARNING for otherwise pretty exceptional cases, like being unable to open a file, or failing network operations. Now normally, you will of course check return values, but if you mess it up, the risk of bad things happening is too big, so right now, it's sensible to treat E_WARNING as fatal in production. E_NOTICEs on the other hand are extremely uncritical (minus the undefined variable case you've highlighted), so it's sensible to ignore those in production and it's tempting to do so even in development and, I freely admit, that's totally the case in the code-base I'm dealing with and I would assume others would also have it configured that way. Code designed to avoid "Undefined index: %s" is very boilerplaty to write and in various code-bases (including ours), accessing undefined indexes in arrays is mostly inconsequential. So this leaves me (and I assume others) in kind of a pickle, because it feels that right now it's still too risky to not treat E_WARNING as fatal in production and on the other hand, this RFC is going to turn completely harmless undefined index access into an E_WARNING. Even if you don't care about my particular code-base (which I would totally understand), please consider that this is quite the BC breakage in general and in our case, it will probably force us to run with a patched PHP engine as we are unable to clean the code up in any kind of reasonable time frame. Again - that's my problem. I know. But I still would like to voice this concern. Of course, even when passing this RFC in full, there are options you could provide for people in our kind of situation: * If all functions that currently emit an E_WARNING in cases where they should actually throw could be made to throw, then it would be safe to run production without treating E_WARNING as fatal. I'm afraid that too is a big BC break, but at least it's breaking code running into otherwise serious issues rather than code doing something mostly benign. * If this can't be done, which I totally understand, then please consider a way for a error handler to distinguish between various errors, notices and warnings without having to string match on error messages. That feels incredibly brittle and also ties the PHP language into ossified error messages that can never be changed without also causing potential BC issues. Still. I wholeheartedly thank you all for your recent efforts to clean up the language and bring it forward to the current state of things. But please consider the huge swaths of existing code which sometimes cannot be practically changed. I do not have any kind of voting rights, so in the end my opinion doesn't matter, but if I had the ability to vote, I would have to vote "no" over this unless some kind of escape hatch is provided. Thank you Philip
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi! > But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1. If you're working in an environment where you aren't sure if $foo has been mentioned already or not (ideally, you never have to, practically, you sometimes are) it's much easier to just do $foo++ than write code to figure out whether $foo has been already initialized. Note that while a lot of PHP code is written in IDE-assisted unit-tested statically-analyzed CI-gated environments, it's not all PHP code. Sometimes you want to do stuff in quick-n-dirty way, even if it's not exactly production grade, and PHP traditionally has been excellent (probably one of the best languages around) for that. I think we shouldn't abandon that. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Javascript has treated undefined variables as a catchable exceptions since (I think?) forever. Perl is the only other language I know that allows them. I've written code in a lot of different languages. Many of those languages (most notably Standard ML) forced me to think about how exactly data flowed through my program. PHP, on the other hand, doesn't demand anything like as much work. This means its developers often don't improve much either, which ultimately this harms the language's reputation as former PHP developers discover their bad habits don't translate well to other languages. With this change we can make it harder for people to write bad code, which I think will result in existing PHP users becoming better developers. On Wed, 28 Aug 2019 at 14:32, Zeev Suraski wrote: > > > On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown > wrote: > >> We log 1 in every 1000 notices, and yes - being notice-free is a goal – >> though not one with any particular timeline at the moment, because we can >> just ignore the problem. I look forward to not being able to ignore the >> problem. > > > When was this goal set? Was there effort that went into it? > > My point is this: > > In a codebase where being notice-free isn't a goal - and/or where code > patterns that rely on the documented behavior of how PHP variables are > initialized as well as behave in read scenarios (with or without the > silence operator) - I think you're going to find a lot of such instances, > probably more so than in a company that made an informed decision to not > allow it and gradually work to remove existing code that uses it. For > many, this is not considered technical debt - but rather - using the > language *as intended*. Using the language in a way that is sanctioned and > considered valid - alongside other ways which are also considered valid > (e.g. a notice-free codebase). > > While I understand what you're saying when you say that you look forward > to not being able to ignore the problem, it sounds like a fairly weak > argument for forcing everyone else - many of whom don't consider this to be > a problem at all - to change their code. Instead, if this bothers you, > make an informed decision to change - there's enough tooling to do that > today with reasonable effort. Or support the ability to flip a switch that > will granularly force you to fix these particular issues. Forcing all > users to work in a certain way, because some of the users who want to work > that way can't bring themselves to do it - doesn't sound very sensible IMHO. > > I was hoping that the glaring obviousness of how other languages tackled > similar issues (Perl, JS) would go a longer way. It should. > > Zeev >
[PHP-DEV] Re: [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: > Hi internals, > > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefined variable" only generating a > notice is really quite mind-boggling. > > I've prepared an RFC with some suggested classifications, though there's > room for bikeshedding here... > > https://wiki.php.net/rfc/engine_warnings > > Regards, > Nikita > It seems quite clear to me that the question of the "undefined variable" error is contentious. As such, I have decided to split it off into a separate section in the proposal, that will be voted separately from the rest. I will offer the choice of throwing an Error exception (as originally proposed), throwing a warning or keeping the existing notice. Reading this discussion has been disappointing and somewhat disillusioning. I can understand and appreciate the concern for legacy code. But seeing the use of undefined variables espoused as a legitimate programming style, that just makes me sad. Regards, Nikita
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 18:45:18 BST, Matthew Brown wrote: >Kicking a house is a poor analogy IMO - most people don’t upgrade a >major >language version without first verifying that their code still works in >the >new version. Probably. Most analogies fall down pretty quickly. I just feel like some of the messages on this thread about technical debt are taking great glee in kicking other people's code, rather than offering to help fix it. Let's talk about how to make this change successful. Let's talk about what tools there are, and what their strengths and limitations are. Let's talk about making people's lives easier now, not punishing them for past mistakes. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 2:32 PM Zeev Suraski wrote: > On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown > wrote: > > > We log 1 in every 1000 notices, and yes - being notice-free is a goal – > > though not one with any particular timeline at the moment, because we can > > just ignore the problem. I look forward to not being able to ignore the > > problem. > > > When was this goal set? Was there effort that went into it? > > My point is this: > > In a codebase where being notice-free isn't a goal - and/or where code > patterns that rely on the documented behavior of how PHP variables are > initialized as well as behave in read scenarios (with or without the > silence operator) - I think you're going to find a lot of such instances, > probably more so than in a company that made an informed decision to not > allow it and gradually work to remove existing code that uses it. For > many, this is not considered technical debt - but rather - using the > language *as intended*. Using the language in a way that is sanctioned and > considered valid - alongside other ways which are also considered valid > (e.g. a notice-free codebase). > For the record, I don't view undeclared variable notices as technical debt either. I've engaged in that discussion at other points because I think this is a bad move even if it is considered technical debt. My personal opinion is that I like the flexibility of the language in this matter. I initialize my variables most of the time anyway, but, I don't think every other PHP developer should be forced to do that just because I like to do it. > > While I understand what you're saying when you say that you look forward to > not being able to ignore the problem, it sounds like a fairly weak argument > for forcing everyone else - many of whom don't consider this to be a > problem at all - to change their code. Instead, if this bothers you, make > an informed decision to change - there's enough tooling to do that today > with reasonable effort. Or support the ability to flip a switch that will > granularly force you to fix these particular issues. Forcing all users to > work in a certain way, because some of the users who want to work that way > can't bring themselves to do it - doesn't sound very sensible IMHO. > > My feelings exactly. What benefits are we getting by FORCING everyone to follow this policy that individual users/companies/development teams can't already gain by just making it a policy and using 3rd party tools to enforce it? What HARM continues to exist in the language if undeclared variables only generate a notice - given the fact that how PHP handles undeclared variables is will documented and, in my opinion, actually a feature of the language? > I was hoping that the glaring obviousness of how other languages tackled > similar issues (Perl, JS) would go a longer way. It should. > > Zeev > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown wrote: > We log 1 in every 1000 notices, and yes - being notice-free is a goal – > though not one with any particular timeline at the moment, because we can > just ignore the problem. I look forward to not being able to ignore the > problem. When was this goal set? Was there effort that went into it? My point is this: In a codebase where being notice-free isn't a goal - and/or where code patterns that rely on the documented behavior of how PHP variables are initialized as well as behave in read scenarios (with or without the silence operator) - I think you're going to find a lot of such instances, probably more so than in a company that made an informed decision to not allow it and gradually work to remove existing code that uses it. For many, this is not considered technical debt - but rather - using the language *as intended*. Using the language in a way that is sanctioned and considered valid - alongside other ways which are also considered valid (e.g. a notice-free codebase). While I understand what you're saying when you say that you look forward to not being able to ignore the problem, it sounds like a fairly weak argument for forcing everyone else - many of whom don't consider this to be a problem at all - to change their code. Instead, if this bothers you, make an informed decision to change - there's enough tooling to do that today with reasonable effort. Or support the ability to flip a switch that will granularly force you to fix these particular issues. Forcing all users to work in a certain way, because some of the users who want to work that way can't bring themselves to do it - doesn't sound very sensible IMHO. I was hoping that the glaring obviousness of how other languages tackled similar issues (Perl, JS) would go a longer way. It should. Zeev
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 2:06 PM Matthew Brown wrote: > I'm no management expert, but I'd be surprised if a boss who won't set > aside time to fix a few undefined variables nevertheless green-lights > rewriting everything in C#. > > It wouldn't be rewrite everything. It would be doing future development using another platform (.NET, node, whatever) and letting the PHP stuff remain like it is. Fixes made when necessary, but, not just for the heck of it. Eventually the PHP stuff will get redone on the new platform and be retired - just like right now the legacy PHP stuff is slowly getting redone or replaced. I don't think that would happen, either, but, the more difficult the upgrade path becomes, the more likely such scenarios will be entertained. We're committed to paying down our technical debt, but, we have to do so on a timeline that fits in with the goals of our business and given our limited resources. If we can't depend on PHP to allow us to pay it down on our timeline, then it might become a choice between not upgrading or doing future development with a platform that doesn't threaten to make the upgrade path something that isn't feasible for us to accomplish. And, to be totally honest, this probably wouldn't cause that much of a delay in our upgrade plans. We'd probably be upgrading to 8.0 around the time that 8.3 was released. Chances are we would be 1 or 2 minor versions behind anyway. We're still on 7.0. We would be on 7.3 but we've experience some difficulties and had to roll back, and currently it's on hold while we knock out a few big projects. However, 10 years ago, my company operated very different. 10 years ago I can see pretty much everything I've talked about being a real possibility. If we operated that way 10 years ago, then there are plenty that still operate that way today. > On Wed, 28 Aug 2019 at 12:26, Chase Peeler wrote: > > > On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote: > > > > > On 28/08/2019 16:37, Chase Peeler wrote: > > > > I'm also not the one that built it on the eggshells - I'm just the > one > > > that > > > > is now in charge of developing the system that someone else left > > sitting > > > > eggshells. > > > > > > That's a challenge which at some point or another will face all > > > technical leads. > > > > > > You have to go to the people making the decisions and say: > > > > > > "Okay, look, we've got ourselves a problem here. We've dug ourselves > > > into a hole by cutting corners, building up debt, and we've never made > > > it a priority to fix it, and now it's causing us problems. It's not one > > > person's fault, it's something that has collectively developed over > > > time, but the reality is, the problem is there and needs fixing." > > > > > > But that's a lie. We have made it a priority to fix things that are > > broken. I wouldn't consider undeclared variables cutting corners. We've > > also invested a lot into making sure we aren't building up additional > > technical debt with the new stuff we're fixing. > > > > > > > And when the manager asks "What problems?" you say something like: > > > > > > "The language we use is moving towards a much stricter approach to > > > handling ambiguous or error prone code. This can only be considered a > > > good thing, but it is going to mean that a lot of our technical debt is > > > going to manifest as errors that will stop our site from function..." > > > > > > Then the manager will go "Can't we just keep using the version we are > > on?" > > > > > > You reply: > > > > > > "We can for a short period, perhaps an extra year or two, but the > > > reality is that PHP is moving forward, and the current version won't be > > > supported forever, and even if it were, we would be missing out on > major > > > performance enhancements and new features that could help us to build > > > new features". > > > > > > Or, they go "Maybe we should look at some options that aren't always > > breaking things. Our other system built with C# has never had that > issue." > > > > > > > The manager says: "Lay this out to me" > > > > > > You reply: > > > > > > "It's like our company car still works, but it no longer tighter meets > > > emissions standards so they won't let us take it into the city any > more" > > > > > > In this case, it's like "Our car still works, but, you the left/right > > arrows on the volume knob have worn off, so, you can't tell by looking at > > it whether you turn it clockwise or counter clockwise to turn up the > > volume. > > > > > > > "Crap", the boss replies "Okay, we had best fix that" > > > > > > Boss replies "Yea, that sounds like a pretty stupid reason to have to > > upgrade. We'll wait." > > > > > > > -- > > > Mark Randall > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > > > -- > > Chase Peeler > > chasepee...@gmail.com > > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
I'm no management expert, but I'd be surprised if a boss who won't set aside time to fix a few undefined variables nevertheless green-lights rewriting everything in C#. On Wed, 28 Aug 2019 at 12:26, Chase Peeler wrote: > On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote: > > > On 28/08/2019 16:37, Chase Peeler wrote: > > > I'm also not the one that built it on the eggshells - I'm just the one > > that > > > is now in charge of developing the system that someone else left > sitting > > > eggshells. > > > > That's a challenge which at some point or another will face all > > technical leads. > > > > You have to go to the people making the decisions and say: > > > > "Okay, look, we've got ourselves a problem here. We've dug ourselves > > into a hole by cutting corners, building up debt, and we've never made > > it a priority to fix it, and now it's causing us problems. It's not one > > person's fault, it's something that has collectively developed over > > time, but the reality is, the problem is there and needs fixing." > > > > But that's a lie. We have made it a priority to fix things that are > broken. I wouldn't consider undeclared variables cutting corners. We've > also invested a lot into making sure we aren't building up additional > technical debt with the new stuff we're fixing. > > > > And when the manager asks "What problems?" you say something like: > > > > "The language we use is moving towards a much stricter approach to > > handling ambiguous or error prone code. This can only be considered a > > good thing, but it is going to mean that a lot of our technical debt is > > going to manifest as errors that will stop our site from function..." > > > > Then the manager will go "Can't we just keep using the version we are > on?" > > > > You reply: > > > > "We can for a short period, perhaps an extra year or two, but the > > reality is that PHP is moving forward, and the current version won't be > > supported forever, and even if it were, we would be missing out on major > > performance enhancements and new features that could help us to build > > new features". > > > > Or, they go "Maybe we should look at some options that aren't always > breaking things. Our other system built with C# has never had that issue." > > > > The manager says: "Lay this out to me" > > > > You reply: > > > > "It's like our company car still works, but it no longer tighter meets > > emissions standards so they won't let us take it into the city any more" > > > > In this case, it's like "Our car still works, but, you the left/right > arrows on the volume knob have worn off, so, you can't tell by looking at > it whether you turn it clockwise or counter clockwise to turn up the > volume. > > > > "Crap", the boss replies "Okay, we had best fix that" > > > > Boss replies "Yea, that sounds like a pretty stupid reason to have to > upgrade. We'll wait." > > > > -- > > Mark Randall > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > -- > Chase Peeler > chasepee...@gmail.com >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019, 5:12 PM Mark Randall wrote: > On 28/08/2019 16:37, Chase Peeler wrote: > > I'm also not the one that built it on the eggshells - I'm just the one > that > > is now in charge of developing the system that someone else left sitting > > eggshells. > > That's a challenge which at some point or another will face all > technical leads. > > You have to go to the people making the decisions and say: > > "Okay, look, we've got ourselves a problem here. We've dug ourselves > into a hole by cutting corners, building up debt, and we've never made > it a priority to fix it, and now it's causing us problems. It's not one > person's fault, it's something that has collectively developed over > time, but the reality is, the problem is there and needs fixing." > > And when the manager asks "What problems?" you say something like: > > "The language we use is moving towards a much stricter approach to > handling ambiguous or error prone code. This can only be considered a > good thing, but it is going to mean that a lot of our technical debt is > going to manifest as errors that will stop our site from function..." > > Then the manager will go "Can't we just keep using the version we are on?" > > You reply: > > "We can for a short period, perhaps an extra year or two, but the > reality is that PHP is moving forward, and the current version won't be > supported forever, and even if it were, we would be missing out on major > performance enhancements and new features that could help us to build > new features". > > The manager says: "Lay this out to me" > > You reply: > > "It's like our company car still works, but it no longer tighter meets > emissions standards so they won't let us take it into the city any more" > > "Crap", the boss replies "Okay, we had best fix that" > > -- > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php This is the best reply with all possible good reasons laid out in few sentences per line ever I've seen on this mailing list. >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Kicking a house is a poor analogy IMO - most people don’t upgrade a major language version without first verifying that their code still works in the new version. And the PHP ecosystem is strong – it's possible to find out today if your code is likely to break (on undefined variables) with both static analysis tools and runtime error handlers. On Wed, 28 Aug 2019 at 13:24, Rowan Collins wrote: > On 28 August 2019 17:53:55 BST, Matthew Brown > wrote: > >It's not breaking all the things - it's breaking code that should have > >been broken already, but somehow wasn't. > > > It's still breaking it though. > > If you realise that a house is built badly and could be destroyed by a > well-aimed kick, you could just give it a kick and say "ah well, not my > fault"; or you could warn the owners, offer help in fixing it, and > understand that they might be too busy to do it right away. > > I don't see why it needs to be such a big deal to ask if this is something > we actually need to kick, right now. > > Regards, > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 17:53:55 BST, Matthew Brown wrote: >It's not breaking all the things - it's breaking code that should have >been broken already, but somehow wasn't. It's still breaking it though. If you realise that a house is built badly and could be destroyed by a well-aimed kick, you could just give it a kick and say "ah well, not my fault"; or you could warn the owners, offer help in fixing it, and understand that they might be too busy to do it right away. I don't see why it needs to be such a big deal to ask if this is something we actually need to kick, right now. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
We log 1 in every 1000 notices, and yes - being notice-free is a goal – though not one with any particular timeline at the moment, because we can just ignore the problem. I look forward to not being able to ignore the problem. On Wed, 28 Aug 2019 at 12:55, Zeev Suraski wrote: > > > On Wed, Aug 28, 2019 at 5:22 PM Matthew Brown > wrote: > >> Looking at our notice logs, I estimate (fairly roughly) that it would >> require about a week's worth of my time to fix these issues in vimeo.com >> ’s >> 700K LOC codebase (the undefined variables are confined to our views). >> > > Can you elaborate a bit about how you generally deal with notices in > vimeo.com - are you generally aiming to be notice-free? Or is that log > collecting a huge amount of messages? > > Zeev >
RE: [PHP-DEV] [RFC] Reclassifying engine warnings
> "It's like our company car still works, but it no longer tighter meets > emissions > standards so they won't let us take it into the city any more" That's a very interesting way to describe error level changes of a language. I wonder what happens when the manager asks - "What's with those guys who bought python/java trucks, go-carts? Do they also have these co2 problems?" Sorry for offtopic .. On a semi related note if the idea/discussion/RFC is for a betterment of language and future regarding warning/errors, it has always puzzled me: - why the engine is so minimalistic/unspecified regarding max_input_vars where the error is just "php-fpm: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0" which isn't very helpful. Also is E_WARNING enough in this case since the variables are forcefully truncated? - and the second is memory_limit which again without any external tooling and/or debug mode while shows the file and line doesn't actually produce meaningful error/backtrace to indicate the problematic part (especially in production environments) We have patched the zend_alloc (in a rough way by searching through symbol_table for fastcgi params) to print more details at least in the fpm-sapi to be able to replicate the issue more easily, but then again I doubt it's the right way to do so.. While the second is hardly related (except the fact it's some sort of programming error condition) doesn't the first one need the same reclassification of error level as undefined variables? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 17:45:50 BST, Marco Pivetta wrote: >The point is that "some organisations do X" is always used as an excuse >for >turning language design mistakes into BC boundaries. No. Things that break compatibility are compatibility breaks. It doesn't matter if they were mistakes or fashions, if code will break, it will break. We can't change that by arguing about workflows and tools. Our job is to decide if and how to make those breaks. So, firstly, we need to agree that their is value to this particular break. I think there probably is, but people may have different opinions. Secondly, we need to think of a sensible way to introduce it. Is it responsible to put a note in an upgrading page and hope everyone spots it? Is there a way we can flag it more loudly? What is the best time frame to roll it out? Is there a way those who want to get it earlier can do so? Does that sound reasonable? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 5:22 PM Matthew Brown wrote: > Looking at our notice logs, I estimate (fairly roughly) that it would > require about a week's worth of my time to fix these issues in vimeo.com’s > 700K LOC codebase (the undefined variables are confined to our views). > Can you elaborate a bit about how you generally deal with notices in vimeo.com - are you generally aiming to be notice-free? Or is that log collecting a huge amount of messages? Zeev
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
It's not breaking all the things - it's breaking code that should have been broken already, but somehow wasn't. On Wed, 28 Aug 2019 at 12:38, Rowan Collins wrote: > On 28 August 2019 16:05:13 BST, Marco Pivetta wrote: > >A week for 700KLOC is *impressively low*. > >Many organisations spend more time on *deciding* whether to upgrade a > >patch > >version of a dependency, and the tooling that vimeo has provided to > >detect > >these issues is technically impressive, and very much usable by other > >orgs > >too. > > > I literally have no idea what to take from that response. Some > organisations are slow, some have cool workflows, so let's break all the > things? > > Regards, > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019, 18:38 Rowan Collins wrote: > On 28 August 2019 16:05:13 BST, Marco Pivetta wrote: > >A week for 700KLOC is *impressively low*. > >Many organisations spend more time on *deciding* whether to upgrade a > >patch > >version of a dependency, and the tooling that vimeo has provided to > >detect > >these issues is technically impressive, and very much usable by other > >orgs > >too. > > > I literally have no idea what to take from that response. Some > organisations are slow, some have cool workflows, so let's break all the > things? > > Regards, > > -- > Rowan Collins > [IMSoP] > The point is that "some organisations do X" is always used as an excuse for turning language design mistakes into BC boundaries. >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 16:05:13 BST, Marco Pivetta wrote: >A week for 700KLOC is *impressively low*. >Many organisations spend more time on *deciding* whether to upgrade a >patch >version of a dependency, and the tooling that vimeo has provided to >detect >these issues is technically impressive, and very much usable by other >orgs >too. I literally have no idea what to take from that response. Some organisations are slow, some have cool workflows, so let's break all the things? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote: > On 28/08/2019 16:37, Chase Peeler wrote: > > I'm also not the one that built it on the eggshells - I'm just the one > that > > is now in charge of developing the system that someone else left sitting > > eggshells. > > That's a challenge which at some point or another will face all > technical leads. > > You have to go to the people making the decisions and say: > > "Okay, look, we've got ourselves a problem here. We've dug ourselves > into a hole by cutting corners, building up debt, and we've never made > it a priority to fix it, and now it's causing us problems. It's not one > person's fault, it's something that has collectively developed over > time, but the reality is, the problem is there and needs fixing." > > But that's a lie. We have made it a priority to fix things that are broken. I wouldn't consider undeclared variables cutting corners. We've also invested a lot into making sure we aren't building up additional technical debt with the new stuff we're fixing. > And when the manager asks "What problems?" you say something like: > > "The language we use is moving towards a much stricter approach to > handling ambiguous or error prone code. This can only be considered a > good thing, but it is going to mean that a lot of our technical debt is > going to manifest as errors that will stop our site from function..." > > Then the manager will go "Can't we just keep using the version we are on?" > > You reply: > > "We can for a short period, perhaps an extra year or two, but the > reality is that PHP is moving forward, and the current version won't be > supported forever, and even if it were, we would be missing out on major > performance enhancements and new features that could help us to build > new features". > > Or, they go "Maybe we should look at some options that aren't always breaking things. Our other system built with C# has never had that issue." > The manager says: "Lay this out to me" > > You reply: > > "It's like our company car still works, but it no longer tighter meets > emissions standards so they won't let us take it into the city any more" > > In this case, it's like "Our car still works, but, you the left/right arrows on the volume knob have worn off, so, you can't tell by looking at it whether you turn it clockwise or counter clockwise to turn up the volume. > "Crap", the boss replies "Okay, we had best fix that" > > Boss replies "Yea, that sounds like a pretty stupid reason to have to upgrade. We'll wait." > -- > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
FWIW: all the runtime notices in our codebase come from internally-created code. Requiring declare(strict_variables=1) to get this (better) behaviour punishes future users of PHP for our past mistakes. > On Aug 28, 2019, at 12:05 PM, Thomas Bley wrote: > > Normally every code base has old and new code, some is actively maintained, > some is probably third-party maintained, some is unmaintained. Business > normally not calculates costs for upgrading, securing, GDPRing old code, so > bigger changes always leave some people behind. > I would prefer to write new code with sth like declare(strict_variables=1); > or declare(SomeNamespace\Foo:strict_variables=1); That way, people can write > new code in a better way, include new libraries and upgrade old code piece by > piece without any big pressure. > > Regards > Thomas > >> Matthew Brown hat am 28. August 2019 um 17:32 >> geschrieben: >> >> >> It's essentially tech debt, and the language has allowed its users to >> accrue a ton of it. >> >> The longer that's allowed (deprecations/warnings prolong the issue in my >> opinion) the harder it will be to fix the issues. >> >>> On Wed, 28 Aug 2019 at 10:56, Rowan Collins wrote: >>> On 28 August 2019 15:22:22 BST, Matthew Brown >>> wrote: Looking at our notice logs, I estimate (fairly roughly) that it would require about a week's worth of my time to fix these issues >>> I honestly thought you were posting that as an argument against. A week of >>> resource (plus the accompanying QA impact etc) is a significant investment >>> for many organisations. That's why it has the potential to delay adoption >>> of a new version, and why a long lead-in via deprecation or opt-in is >>> necessary. >>> Regards, >>> -- >>> Rowan Collins >>> [IMSoP] >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28/08/2019 16:37, Chase Peeler wrote: I'm also not the one that built it on the eggshells - I'm just the one that is now in charge of developing the system that someone else left sitting eggshells. That's a challenge which at some point or another will face all technical leads. You have to go to the people making the decisions and say: "Okay, look, we've got ourselves a problem here. We've dug ourselves into a hole by cutting corners, building up debt, and we've never made it a priority to fix it, and now it's causing us problems. It's not one person's fault, it's something that has collectively developed over time, but the reality is, the problem is there and needs fixing." And when the manager asks "What problems?" you say something like: "The language we use is moving towards a much stricter approach to handling ambiguous or error prone code. This can only be considered a good thing, but it is going to mean that a lot of our technical debt is going to manifest as errors that will stop our site from function..." Then the manager will go "Can't we just keep using the version we are on?" You reply: "We can for a short period, perhaps an extra year or two, but the reality is that PHP is moving forward, and the current version won't be supported forever, and even if it were, we would be missing out on major performance enhancements and new features that could help us to build new features". The manager says: "Lay this out to me" You reply: "It's like our company car still works, but it no longer tighter meets emissions standards so they won't let us take it into the city any more" "Crap", the boss replies "Okay, we had best fix that" -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hello, as many later posters in the thread have said - a lot of notices, especially uninitialised variables, are classic technical debt. For example, I just recently fixed a bug, that did this: `$array['key'] += $cost` - the array key was not initialised. Well, turned out that in this case instead of null, it actually grabbed some garbage number out of memory and screwed up the calculations where the total was off by a few hundred euro. Previous dev did care about notices and/or warnings and god knows how long that issue was in production and how many calculations it affected before it was caught. There is also another side effect on performance. error handling in PHP is not free - it does take some significant amount of time. And the more warnings/notices like that you have, the bigger the impact. I have migrated an old code base that was riddled with notices - just fixing those improved performance by 100% without adjusting anything else. Single page load generated 3.5MB of notices and warnings. It also fixed quite a few bugs just because vars got their proper initial values. >From time to time I get reminded when I go back into the crappy code how unpredictable it can be. And the point about PHP 's future. Planning should be done for at least the next 10 years and in today's environment, PHP needs a stricter mode that is just across the board. A project that I start today is by default in strict types mode, PHPStorm has 99.9% of inspections enabled, code analysers are configured and you will not be able to leave a potentially undefined variable in my codebase. git commit hook will just reject it. Frankly, today I do not care what PHP was 5 years ago and how people used it. I care what PHP is today and will be in 5 years when my app goes into production and is actively developed. I also dedicate resources in my budget to keep our software up to date and perform TLC on it. I just do not allow the business to ignore it. A lot of that TLC is done by just regular development workflow - you see crap, you take 5 minutes to fix it. A lot of the time executives don't even know we did the TLC, nor they even should - that's part of our daily responsibilities.
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Normally every code base has old and new code, some is actively maintained, some is probably third-party maintained, some is unmaintained. Business normally not calculates costs for upgrading, securing, GDPRing old code, so bigger changes always leave some people behind. I would prefer to write new code with sth like declare(strict_variables=1); or declare(SomeNamespace\Foo:strict_variables=1); That way, people can write new code in a better way, include new libraries and upgrade old code piece by piece without any big pressure. Regards Thomas > Matthew Brown hat am 28. August 2019 um 17:32 > geschrieben: > > > It's essentially tech debt, and the language has allowed its users to > accrue a ton of it. > > The longer that's allowed (deprecations/warnings prolong the issue in my > opinion) the harder it will be to fix the issues. > > On Wed, 28 Aug 2019 at 10:56, Rowan Collins wrote: > > On 28 August 2019 15:22:22 BST, Matthew Brown > > wrote: > > >Looking at our notice logs, I estimate (fairly roughly) that it would > > >require about a week's worth of my time to fix these issues > > I honestly thought you were posting that as an argument against. A week of > > resource (plus the accompanying QA impact etc) is a significant investment > > for many organisations. That's why it has the potential to delay adoption > > of a new version, and why a long lead-in via deprecation or opt-in is > > necessary. > > Regards, > > -- > > Rowan Collins > > [IMSoP] > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen wrote: > Hi > > Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler >: > > You going to come and fix the issues? It's an internal application and > > most of those messages are coming from legacy areas of the code which are > > mainly "it works, so leave it alone" things. Instead of going back and > > spending time trying to fix those boondoggles, we invest the time of our > > developers (there are 2 others besides myself) into building new features > > that help our business grow. Time permitting, we try and update some of > the > > legacy areas, but, we usually find it's a better investment to just > rebuild > > them at that point. > > > > Bottom line is that we live with the not-so-good stuff so that we can > focus > > on adding new great stuff. The not-so-good stuff isn't holding us back, > and > > trying to fix things like undeclared variables would have absolutely ZERO > > positive effect on our business, which uses this application every day. > If > > I went to our executive team and said "Can we delay that new scheduling > > system that will really help our business so I can go back and update > code > > to get rid of these undeclared variable notices?" I'd get laughed at! > > > > Like I've said before - can we please stop pretending we understand > > everyone else's situation? Maybe my situation is unique. My gut tells me > it > > might be unique among people on this list, but, that it's actually pretty > > common among the myriad of developers out there which never get involved > in > > these discussions. > > I'm sorry, but like Mark Randall has already pointed out then this is > a classic example of technical depth. At one point you must choose, > "Do I want to upgrade to the latest version of PHP or do I want to fix > the issues which is caused by the technical depth in my stack?". I don't get to make that choice, though. The executives do. > I get > it, writing new code is always more fun, it really is, It's not about what is more fun. It's about what is necessary for our company to grow, move forward, and survive. What good is fixing old code if our company withers away while we do it since we aren't supporting them with the new things the need to move forward? We aren't building things on top of that old code, so, the new things we build aren't accruing additional technical debt as a result of the existing technical debt. I have > previously worked with companies with that same attitude that "we'll > fix it later", but at one point that becomes such a burden and if your > management doesn't believe in putting in resources to actual > maintenance of your infrastructure, then I'm sorry but it does not > sound like a healthy place to be (no offense meant). > > That's not exactly our attitude. If something is really broken, we fix it. We are not focusing our limited resources on updating things that currently work just because we don't like how they were built. Most of it was done 10-15 years ago, and, even if we had the resources to update it, we'd be better off just rebuilding it altogether. Let me focus on the technical debt that has high interest, instead of the debt that doesn't really impact anything, like undeclared variables. > Right now your argument is merely trying to hold back changes which > will bite that technical depth of yours, and everytime an argument has > been raised towards your concerns it has been met with "Will you come > and fix it?", "I demand that X, Y or Z tool is available for me to > use", etc., so again, I'm sorry but I'm not buying this argument. > > No, it's just that we should weigh the positives and the negatives. If we want to move PHP forward, we need to look at new features, and fixing old things that are really broken. I don't consider undeclared variables only generating a notice to be something that's "really broken." It still might be worth doing, though, if there isn't much of a reason not too. The current system doesn't prevent anyone from properly initializing their variables. Nothing prevents a company from doing code reviews or employing other tools to make sure their developers always initialize their variables. Why do we have to FORCE everyone else that wants to use PHP to do that as well? To me, what makes PHP great is its flexibility. Does that mean some people out there write some really bad code? Yes, it does. Heck, a lot of that code lives in our legacy code base and was probably written by me. But, the flexibility doesn't PREVENT anyone from writing truly great code, either. The only things that prevents great code are the great features we haven't implemented. Instead of focusing on those, it seems we spend our time trying to decide how we can take away some of the languages strengths. Even if you don't view it as a strength, is it really such a weakness that it's hurting the language? Some things we can solve by an opt-in, like the strict_types declare, > however other
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 11:12 AM Mark Randall wrote: > On 28/08/2019 15:54, Chase Peeler wrote: > > Bottom line is that we live with the not-so-good stuff so that we can > focus > > on adding new great stuff. The not-so-good stuff isn't holding us back, > and > > trying to fix things like undeclared variables would have absolutely ZERO > > positive effect on our business, which uses this application every day. > > This is a classic case of technical debt. It might not bite you in the > ass today, tomorrow, or next week, but it will inevitably bite you in > the ass at some point, and the longer it's left, the more it's going to > hurt when that time comes. > Yes, it is. However, it's technical debt that is no longer growing. We make payments on it when we can, but, the majority of our limited resources are focused on building new things, we a careful focus on minimizing technical debt as much as possible (I don't think it's possible to totally avoid it). > Don't build your business on a foundation of eggshells and then complain > when something comes along that makes those eggshells crumble. > > I think our foundation is a bit stronger than that, but, I'll go with the analogy: All I'm asking is that we don't purposely try and break those eggshells if it isn't necessary. I'm also not the one that built it on the eggshells - I'm just the one that is now in charge of developing the system that someone else left sitting eggshells. I'm the one in charge of making sure our business (not a software company, by the way) that uses that system continues to grow, regardless of whether it's built on eggshells or diamonds. > -- > Mark Randall > > Just keep in mind that the harder the upgrade path is, the more people there are that just won't do it. Whether they stick with an old version of PHP forever or switch to something else entirely. If the reason the upgrade path is so difficult is for something that the users don't even perceive as a benefit, it's even more likely to drive them away. Tell me how this benefits: 1) The user that already initializes their variables 2) The user that actually utilizes the fact that you don't have to initialize your variables. I would say it has no benefit to the first person, but, it doesn't hurt them either. It actually hurts the second person. The main benefits I see from this is that it will: 1.) help people that do want to initialize their variables find places where they forgot to do so. There are tons of tools, including most IDEs, which will also do this. 2.) Force new developers to conform to what some people view as a best practice 3.) Allow those that want to make PHP a more strict and less forgiving language to cram that down the throat of all of the users that don't want to see that. > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler : > You going to come and fix the issues? It's an internal application and > most of those messages are coming from legacy areas of the code which are > mainly "it works, so leave it alone" things. Instead of going back and > spending time trying to fix those boondoggles, we invest the time of our > developers (there are 2 others besides myself) into building new features > that help our business grow. Time permitting, we try and update some of the > legacy areas, but, we usually find it's a better investment to just rebuild > them at that point. > > Bottom line is that we live with the not-so-good stuff so that we can focus > on adding new great stuff. The not-so-good stuff isn't holding us back, and > trying to fix things like undeclared variables would have absolutely ZERO > positive effect on our business, which uses this application every day. If > I went to our executive team and said "Can we delay that new scheduling > system that will really help our business so I can go back and update code > to get rid of these undeclared variable notices?" I'd get laughed at! > > Like I've said before - can we please stop pretending we understand > everyone else's situation? Maybe my situation is unique. My gut tells me it > might be unique among people on this list, but, that it's actually pretty > common among the myriad of developers out there which never get involved in > these discussions. I'm sorry, but like Mark Randall has already pointed out then this is a classic example of technical depth. At one point you must choose, "Do I want to upgrade to the latest version of PHP or do I want to fix the issues which is caused by the technical depth in my stack?". I get it, writing new code is always more fun, it really is, I have previously worked with companies with that same attitude that "we'll fix it later", but at one point that becomes such a burden and if your management doesn't believe in putting in resources to actual maintenance of your infrastructure, then I'm sorry but it does not sound like a healthy place to be (no offense meant). Right now your argument is merely trying to hold back changes which will bite that technical depth of yours, and everytime an argument has been raised towards your concerns it has been met with "Will you come and fix it?", "I demand that X, Y or Z tool is available for me to use", etc., so again, I'm sorry but I'm not buying this argument. Some things we can solve by an opt-in, like the strict_types declare, however other things so fundamental to the language should not have any options to alter its behavior, that should be consistent. We have spend a long time trying to carve a migration path and advocate against options which changes language behavior across installations. If we continue down this path, then its just a runtime version of php.ini with a million declare statements on top of each file, each having multiple meanings and an added complexity to maintain the code, not a burden I think userland developers need as it is. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
It's essentially tech debt, and the language has allowed its users to accrue a ton of it. The longer that's allowed (deprecations/warnings prolong the issue in my opinion) the harder it will be to fix the issues. On Wed, 28 Aug 2019 at 10:56, Rowan Collins wrote: > On 28 August 2019 15:22:22 BST, Matthew Brown > wrote: > >Looking at our notice logs, I estimate (fairly roughly) that it would > >require about a week's worth of my time to fix these issues > > I honestly thought you were posting that as an argument against. A week of > resource (plus the accompanying QA impact etc) is a significant investment > for many organisations. That's why it has the potential to delay adoption > of a new version, and why a long lead-in via deprecation or opt-in is > necessary. > > Regards, > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28/08/2019 15:54, Chase Peeler wrote: Bottom line is that we live with the not-so-good stuff so that we can focus on adding new great stuff. The not-so-good stuff isn't holding us back, and trying to fix things like undeclared variables would have absolutely ZERO positive effect on our business, which uses this application every day. This is a classic case of technical debt. It might not bite you in the ass today, tomorrow, or next week, but it will inevitably bite you in the ass at some point, and the longer it's left, the more it's going to hurt when that time comes. Don't build your business on a foundation of eggshells and then complain when something comes along that makes those eggshells crumble. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 4:56 PM Rowan Collins wrote: > On 28 August 2019 15:22:22 BST, Matthew Brown > wrote: > >Looking at our notice logs, I estimate (fairly roughly) that it would > >require about a week's worth of my time to fix these issues > > I honestly thought you were posting that as an argument against. A week of > resource (plus the accompanying QA impact etc) is a significant investment > for many organisations. That's why it has the potential to delay adoption > of a new version, and why a long lead-in via deprecation or opt-in is > necessary. > A week for 700KLOC is *impressively low*. Many organisations spend more time on *deciding* whether to upgrade a patch version of a dependency, and the tooling that vimeo has provided to detect these issues is technically impressive, and very much usable by other orgs too. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 15:22:22 BST, Matthew Brown wrote: >Looking at our notice logs, I estimate (fairly roughly) that it would >require about a week's worth of my time to fix these issues I honestly thought you were posting that as an argument against. A week of resource (plus the accompanying QA impact etc) is a significant investment for many organisations. That's why it has the potential to delay adoption of a new version, and why a long lead-in via deprecation or opt-in is necessary. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 10:39 AM Marco Pivetta wrote: > On Wed, Aug 28, 2019 at 4:27 PM Chase Peeler > wrote: > >> On Wed, Aug 28, 2019 at 10:20 AM Gert wrote: >> Notices include a lot more than just undeclared variables. Turning them on >> in our environment would pretty much make the logs unusable for any on the >> spot checking for issues. They would only be useful if we were trying to >> parse out specific errors, and, they would be HUGE. Each web server >> generates about 5-10 megs of logs in a day. Our CLI servers (which runs >> beanstalkd jobs) generates about 80-100 megs of logs in a day. That's >> without notices turned on. > > > I worked with clients with much more log overhead happening: the solution > is working to fix these issues, and not ignoring more of them. > > You going to come and fix the issues? It's an internal application and most of those messages are coming from legacy areas of the code which are mainly "it works, so leave it alone" things. Instead of going back and spending time trying to fix those boondoggles, we invest the time of our developers (there are 2 others besides myself) into building new features that help our business grow. Time permitting, we try and update some of the legacy areas, but, we usually find it's a better investment to just rebuild them at that point. Bottom line is that we live with the not-so-good stuff so that we can focus on adding new great stuff. The not-so-good stuff isn't holding us back, and trying to fix things like undeclared variables would have absolutely ZERO positive effect on our business, which uses this application every day. If I went to our executive team and said "Can we delay that new scheduling system that will really help our business so I can go back and update code to get rid of these undeclared variable notices?" I'd get laughed at! Like I've said before - can we please stop pretending we understand everyone else's situation? Maybe my situation is unique. My gut tells me it might be unique among people on this list, but, that it's actually pretty common among the myriad of developers out there which never get involved in these discussions. > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 15:39:26 BST, Marco Pivetta wrote: >I worked with clients with much more log overhead happening: the >solution >is working to fix these issues, and not ignoring more of them. Being right is not the same as being easy, or being the top priority for an organisation with limited resources. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 15:24:33 BST, Mark Randall wrote: >By the very nature of using @ to suppress error messages, the examples >given are all fully aware that the behaviour they are using is not good >practice. I think that is a fault in the examples. I have never seen @ used to squash these messages, but have frequently worked with codebases where logging at the E_NOTICE level would have filled megabytes of log file in minutes. As I said earlier, the fact that something is bad practice doesn't stop it being difficult to locate and change. The requests for a deprecation period, or an opt-in mode, are about that change, not a disagreement about the principle. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 4:27 PM Chase Peeler wrote: > On Wed, Aug 28, 2019 at 10:20 AM Gert wrote: > Notices include a lot more than just undeclared variables. Turning them on > in our environment would pretty much make the logs unusable for any on the > spot checking for issues. They would only be useful if we were trying to > parse out specific errors, and, they would be HUGE. Each web server > generates about 5-10 megs of logs in a day. Our CLI servers (which runs > beanstalkd jobs) generates about 80-100 megs of logs in a day. That's > without notices turned on. I worked with clients with much more log overhead happening: the solution is working to fix these issues, and not ignoring more of them. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 10:20 AM Gert wrote: > Maybe i'm misunderstanding something here, but what does turning > notices into deprecations achieve? Because if you have deprecation > notices being logged then it shouldn't be extra work to log > notices/warnings as well right? > > Notices include a lot more than just undeclared variables. Turning them on in our environment would pretty much make the logs unusable for any on the spot checking for issues. They would only be useful if we were trying to parse out specific errors, and, they would be HUGE. Each web server generates about 5-10 megs of logs in a day. Our CLI servers (which runs beanstalkd jobs) generates about 80-100 megs of logs in a day. That's without notices turned on. > On Wed, 28 Aug 2019 at 16:16, Chase Peeler wrote: > > > > Well, one reason I was so vocal about short tags wasn't a love for short > > tags themselves. It wasn't even to prevent the detrimental effects of > > removing them. Honestly, the 2nd RFC wasn't a horrible option. It was > more > > about the precedent that it set - pushing huge BC breaks on the users > (most > > of which are voiceless in the process, because they aren't involved in > the > > community at all, most not really aware there is anything to be involved > > with) with little, if any, positive gain. > > > > Let's see how this plays out a bit longer. It's too early to tell if > it's a > > dying attempt to keep pushing those type of changes, which are destined > to > > be rejected, or, evidence that we are still in danger of having such a > > precedent set. > > > > > > > > On Wed, Aug 28, 2019 at 10:11 AM Chase Peeler > wrote: > > > > > > > > > > > On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald > > > wrote: > > > > > >> > > >> > > >> Am 28.08.19 um 15:48 schrieb Chase Peeler: > > >> > If it is still done, then I think a deprecation path is a must. As > > >> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION > messages > > >> - > > >> > warnings will work too. The key is that error logs with more urgency > > >> than > > >> > notices are created that users can use to track down and fix issues. > > >> > > >> hell, there are notices for at least a decade > > >> > > >> error_log = "/var/log/php_error.log" > > >> error_reporting = E_ALL > > >> display_errors = 1 > > >> > > >> this is my development *as well* production config on every machine > > >> since 16 years now and every warning/notice get fixed because every 30 > > >> minutes the errorlog get mailed to every developer and admin > > >> > > >> turn logging on and start cleanup what you would have had a decade > time. > > > > > > > > > Am I the only one getting tired of people telling me how I need to > operate > > > just like they do? Everyone's circumstances are different. Just because > > > something is easy for you, or works well for you, doesn't mean it's > easy or > > > even feasible for someone else. I've learned it's useless to try to > explain > > > how my situation might not be exactly like everyone else's, so I'm not > > > going to waste the time doing it again. > > > > > > Why can't anyone see that taking on these myopic "My situation is the > only > > > valid situation" views are going to kill this language. > > > > > > "I always initialize my variables, so, it's no big deal if everyone > else > > > is forced to do so." > > > "I was able to find and replace all the short tags in my code in 5 > > > minutes, so it should be easy for everyone else to do as well." > > > "We fix every single notice within 30 minutes of it popping up in a > log. > > > You should be able to do that as well." > > > etc. etc. etc. > > > > > > Also, if you are going to try and tell me how I should my job, at least > > > have the guts to reply to the entire list instead of sending it to me > in a > > > private reply. I'm obviously not afraid to turn around to make your > reply > > > public, so it'll save everyone a bit of time. > > > > > > -- > > > Chase Peeler > > > chasepee...@gmail.com > > > > > > > > > -- > > Chase Peeler > > chasepee...@gmail.com > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28/08/2019 14:48, Chase Peeler wrote: My position is that this should be done as an opt-in feature like Zeev as proposed. If it is not done as an opt-in feature, then I don't think it should be done at all. IMO one shouldn't have to opt-in to use common-sense error checking of engine operations. It's essential to think of the long-term future of PHP and what makes sense going forward, and to my mind that means things need to be more intuitive and less prone to mistakes. Be it Little Jonny Just-Grad who is starting his first proper PHP project, or the lead engineer of Megacorp, Inc. who is about to write the first line of the company's next multi-million dollar hit, they shouldn't need to pile-up on declares at the top of each page just to make the engine perform as intuitive common sense would dictate. By the very nature of using @ to suppress error messages, the examples given are all fully aware that the behaviour they are using is not good practice. If the engine was perfectly confident in your use of the statements that followed it, then it wouldn't display an error that you would need to suppress in the first place, now would it? Besides, we have tools available for years now to make this behaviour more defined: $counts[$key] = ($counts[$key] ?? 0) + 1; "If $counts[$key] is not set, use the value 0". Null Coalescing was explicitly designed to provide for this behaviour. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Looking at our notice logs, I estimate (fairly roughly) that it would require about a week's worth of my time to fix these issues in vimeo.com’s 700K LOC codebase (the undefined variables are confined to our views). IMO it's akin to taking the training wheels off the language – I think the PHP ecosystem is mature enough to deal with the change. On Wed, 28 Aug 2019 at 05:34, Nikita Popov wrote: > Hi internals, > > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefined variable" only generating a > notice is really quite mind-boggling. > > I've prepared an RFC with some suggested classifications, though there's > room for bikeshedding here... > > https://wiki.php.net/rfc/engine_warnings > > Regards, > Nikita >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Maybe i'm misunderstanding something here, but what does turning notices into deprecations achieve? Because if you have deprecation notices being logged then it shouldn't be extra work to log notices/warnings as well right? On Wed, 28 Aug 2019 at 16:16, Chase Peeler wrote: > > Well, one reason I was so vocal about short tags wasn't a love for short > tags themselves. It wasn't even to prevent the detrimental effects of > removing them. Honestly, the 2nd RFC wasn't a horrible option. It was more > about the precedent that it set - pushing huge BC breaks on the users (most > of which are voiceless in the process, because they aren't involved in the > community at all, most not really aware there is anything to be involved > with) with little, if any, positive gain. > > Let's see how this plays out a bit longer. It's too early to tell if it's a > dying attempt to keep pushing those type of changes, which are destined to > be rejected, or, evidence that we are still in danger of having such a > precedent set. > > > > On Wed, Aug 28, 2019 at 10:11 AM Chase Peeler wrote: > > > > > > > On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald > > wrote: > > > >> > >> > >> Am 28.08.19 um 15:48 schrieb Chase Peeler: > >> > If it is still done, then I think a deprecation path is a must. As > >> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages > >> - > >> > warnings will work too. The key is that error logs with more urgency > >> than > >> > notices are created that users can use to track down and fix issues. > >> > >> hell, there are notices for at least a decade > >> > >> error_log = "/var/log/php_error.log" > >> error_reporting = E_ALL > >> display_errors = 1 > >> > >> this is my development *as well* production config on every machine > >> since 16 years now and every warning/notice get fixed because every 30 > >> minutes the errorlog get mailed to every developer and admin > >> > >> turn logging on and start cleanup what you would have had a decade time. > > > > > > Am I the only one getting tired of people telling me how I need to operate > > just like they do? Everyone's circumstances are different. Just because > > something is easy for you, or works well for you, doesn't mean it's easy or > > even feasible for someone else. I've learned it's useless to try to explain > > how my situation might not be exactly like everyone else's, so I'm not > > going to waste the time doing it again. > > > > Why can't anyone see that taking on these myopic "My situation is the only > > valid situation" views are going to kill this language. > > > > "I always initialize my variables, so, it's no big deal if everyone else > > is forced to do so." > > "I was able to find and replace all the short tags in my code in 5 > > minutes, so it should be easy for everyone else to do as well." > > "We fix every single notice within 30 minutes of it popping up in a log. > > You should be able to do that as well." > > etc. etc. etc. > > > > Also, if you are going to try and tell me how I should my job, at least > > have the guts to reply to the entire list instead of sending it to me in a > > private reply. I'm obviously not afraid to turn around to make your reply > > public, so it'll save everyone a bit of time. > > > > -- > > Chase Peeler > > chasepee...@gmail.com > > > > > -- > Chase Peeler > chasepee...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Well, one reason I was so vocal about short tags wasn't a love for short tags themselves. It wasn't even to prevent the detrimental effects of removing them. Honestly, the 2nd RFC wasn't a horrible option. It was more about the precedent that it set - pushing huge BC breaks on the users (most of which are voiceless in the process, because they aren't involved in the community at all, most not really aware there is anything to be involved with) with little, if any, positive gain. Let's see how this plays out a bit longer. It's too early to tell if it's a dying attempt to keep pushing those type of changes, which are destined to be rejected, or, evidence that we are still in danger of having such a precedent set. On Wed, Aug 28, 2019 at 10:11 AM Chase Peeler wrote: > > > On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald > wrote: > >> >> >> Am 28.08.19 um 15:48 schrieb Chase Peeler: >> > If it is still done, then I think a deprecation path is a must. As >> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages >> - >> > warnings will work too. The key is that error logs with more urgency >> than >> > notices are created that users can use to track down and fix issues. >> >> hell, there are notices for at least a decade >> >> error_log = "/var/log/php_error.log" >> error_reporting = E_ALL >> display_errors = 1 >> >> this is my development *as well* production config on every machine >> since 16 years now and every warning/notice get fixed because every 30 >> minutes the errorlog get mailed to every developer and admin >> >> turn logging on and start cleanup what you would have had a decade time. > > > Am I the only one getting tired of people telling me how I need to operate > just like they do? Everyone's circumstances are different. Just because > something is easy for you, or works well for you, doesn't mean it's easy or > even feasible for someone else. I've learned it's useless to try to explain > how my situation might not be exactly like everyone else's, so I'm not > going to waste the time doing it again. > > Why can't anyone see that taking on these myopic "My situation is the only > valid situation" views are going to kill this language. > > "I always initialize my variables, so, it's no big deal if everyone else > is forced to do so." > "I was able to find and replace all the short tags in my code in 5 > minutes, so it should be easy for everyone else to do as well." > "We fix every single notice within 30 minutes of it popping up in a log. > You should be able to do that as well." > etc. etc. etc. > > Also, if you are going to try and tell me how I should my job, at least > have the guts to reply to the entire list instead of sending it to me in a > private reply. I'm obviously not afraid to turn around to make your reply > public, so it'll save everyone a bit of time. > > -- > Chase Peeler > chasepee...@gmail.com > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald wrote: > > > Am 28.08.19 um 15:48 schrieb Chase Peeler: > > If it is still done, then I think a deprecation path is a must. As > > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages - > > warnings will work too. The key is that error logs with more urgency than > > notices are created that users can use to track down and fix issues. > > hell, there are notices for at least a decade > > error_log = "/var/log/php_error.log" > error_reporting = E_ALL > display_errors = 1 > > this is my development *as well* production config on every machine > since 16 years now and every warning/notice get fixed because every 30 > minutes the errorlog get mailed to every developer and admin > > turn logging on and start cleanup what you would have had a decade time. Am I the only one getting tired of people telling me how I need to operate just like they do? Everyone's circumstances are different. Just because something is easy for you, or works well for you, doesn't mean it's easy or even feasible for someone else. I've learned it's useless to try to explain how my situation might not be exactly like everyone else's, so I'm not going to waste the time doing it again. Why can't anyone see that taking on these myopic "My situation is the only valid situation" views are going to kill this language. "I always initialize my variables, so, it's no big deal if everyone else is forced to do so." "I was able to find and replace all the short tags in my code in 5 minutes, so it should be easy for everyone else to do as well." "We fix every single notice within 30 minutes of it popping up in a log. You should be able to do that as well." etc. etc. etc. Also, if you are going to try and tell me how I should my job, at least have the guts to reply to the entire list instead of sending it to me in a private reply. I'm obviously not afraid to turn around to make your reply public, so it'll save everyone a bit of time. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 9:30 AM Chase Peeler wrote:
>
>
> On Wed, Aug 28, 2019 at 8:35 AM Zeev Suraski wrote:
>
>> On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov
>> wrote:
>>
>> > On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>> >
>> >>
>> >>
>> >> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov
>> >> wrote:
>> >>
>> >>> Hi internals,
>> >>>
>> >>> I think it's time to take a look at our existing warnings & notices in
>> >>> the
>> >>> engine, and think about whether their current classification is still
>> >>> appropriate. Error conditions like "undefined variable" only
>> generating a
>> >>> notice is really quite mind-boggling.
>> >>>
>> >>> I've prepared an RFC with some suggested classifications, though
>> there's
>> >>> room for bikeshedding here...
>> >>>
>> >>> https://wiki.php.net/rfc/engine_warnings
>> >>
>> >>
>> >> Specifically on undefined variables, the way we deal with them has
>> little
>> >> to do with register_globals. It's behavior you can find in other
>> >> dynamic languages (e.g. Perl), and allows for certain code patterns
>> (which
>> >> rely on the automatic creation of a variable whenever it's used in
>> write
>> >> context, and on a default known-in-advance value in case it's used in a
>> >> read context). It's fine not to like this behavior or the code
>> patterns
>> >> that commonly rely on it (e.g., @$foo++), but it's intentional and
>> isn't
>> >> related to any historical reasons.
>> >>
>> >
>> > This argument makes sense for arrays and objects (and I don't promote
>> > undefined index/property to exceptions for that reason), but I don't
>> think
>> > it holds any water for simple variables. Writing @$counts[$key]++ is a
>> lazy
>> > way to count values and avoid ugly boilerplate for if
>> > (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }.
>> > But @$foo++ is just a really bad way of writing either $foo++ or $foo =
>> 1.
>> > Outside of variable variables, the concept of a conditionally defined
>> > variable just doesn't make a lot of sense.
>> >
>>
>> This example has nothing to do with arrays. There are many code patterns
>> in which relying on this behavior makes perfect sense for folks who are a
>> lot less strictly-minded. For example:
>>
>> foreach (whatever) {
>> if (sth) {
>> @$whCount++;
>> }
>> }
>>
>> Yes, it may be painful for many eyes that $whCount is not explicitly
>> initialized, but the above code is perfectly legitimate, warning-free
>> notice-compliant code since forever. Moreover - this isn't legacy - there
>> are a lot of folks who appreciate this precise behavior, which is
>> documented and works as expected for the last 20+ years.
>>
>> Or:
>>
>> if ($bookCount>0) {
>> $suffix = 's';
>> }
>>
>> print "$bookCount book$suffix";
>>
>> These are just two simple cases I bumped into myself recently. There's an
>> infinite supply of more of those where these came from.
>>
>>
>> >
>> >> I think many (if not all) of your proposals make sense, but most of
>> them
>> >> make sense as an opt-in - perhaps using something similar to Perl's
>> strict
>> >> mode (which incidentally, changes the way the language treats undefined
>> >> variables in exactly the same way). This would also provide a
>> future-proof
>> >> solution for additional similarly-themed proposals (such as strict ops,
>> >> etc.).
>> >>
>> >
>> > I don't think this is an appropriate use of an opt-in. It's a case where
>> > we can balance language cleanup with backwards compatibility concerns.
>> Code
>> > that works after this proposal will also work before it, and as such
>> there
>> > is no danger of ecosystem bifurcation that would need to be addressed
>> by an
>> > opt-in.
>> >
>>
>> Calling this 'cleanup' is opinionated, and avoiding bifurcation by forcing
>> that opinion on everyone isn't a very good solution for those who have
>> other opinions. While the opinion that variables must not be used before
>> being initialized is obviously a valid one - it is just that, one valid
>> opinion - and there are others. PHP never took this opinion as an
>> axiomatic requirement (and not because of register_globals) - instead, the
>> intent was to have a default value for uninitialized variables - a
>> consistent, documented behavior since the dawn of the language. Can this
>> be problematic under certain situations? Absolutely. Can it be useful in
>> other cases? Sure (which is why it's very common). A great deal of folks
>> both rely on this behavior and *like *it. Those who don't (and there's
>> plenty of those as well of course) - always had a reasonable solution of
>> enabling E_STRICT and enforcing E_STRICT-compliant code. I still think
>> that having a strict mode (which can encompass strict types, strict ops,
>> stricter error behavior, etc.) makes a lot of sense and would arguably be
>> a
>> superior option for the many folks who prefer a stricter language - but
>> there's simply no way we can change one of the most fundamental behaviors
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 8:35 AM Zeev Suraski wrote:
> On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov wrote:
>
> > On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
> >
> >>
> >>
> >> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov
> >> wrote:
> >>
> >>> Hi internals,
> >>>
> >>> I think it's time to take a look at our existing warnings & notices in
> >>> the
> >>> engine, and think about whether their current classification is still
> >>> appropriate. Error conditions like "undefined variable" only
> generating a
> >>> notice is really quite mind-boggling.
> >>>
> >>> I've prepared an RFC with some suggested classifications, though
> there's
> >>> room for bikeshedding here...
> >>>
> >>> https://wiki.php.net/rfc/engine_warnings
> >>
> >>
> >> Specifically on undefined variables, the way we deal with them has
> little
> >> to do with register_globals. It's behavior you can find in other
> >> dynamic languages (e.g. Perl), and allows for certain code patterns
> (which
> >> rely on the automatic creation of a variable whenever it's used in write
> >> context, and on a default known-in-advance value in case it's used in a
> >> read context). It's fine not to like this behavior or the code patterns
> >> that commonly rely on it (e.g., @$foo++), but it's intentional and isn't
> >> related to any historical reasons.
> >>
> >
> > This argument makes sense for arrays and objects (and I don't promote
> > undefined index/property to exceptions for that reason), but I don't
> think
> > it holds any water for simple variables. Writing @$counts[$key]++ is a
> lazy
> > way to count values and avoid ugly boilerplate for if
> > (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }.
> > But @$foo++ is just a really bad way of writing either $foo++ or $foo =
> 1.
> > Outside of variable variables, the concept of a conditionally defined
> > variable just doesn't make a lot of sense.
> >
>
> This example has nothing to do with arrays. There are many code patterns
> in which relying on this behavior makes perfect sense for folks who are a
> lot less strictly-minded. For example:
>
> foreach (whatever) {
> if (sth) {
> @$whCount++;
> }
> }
>
> Yes, it may be painful for many eyes that $whCount is not explicitly
> initialized, but the above code is perfectly legitimate, warning-free
> notice-compliant code since forever. Moreover - this isn't legacy - there
> are a lot of folks who appreciate this precise behavior, which is
> documented and works as expected for the last 20+ years.
>
> Or:
>
> if ($bookCount>0) {
> $suffix = 's';
> }
>
> print "$bookCount book$suffix";
>
> These are just two simple cases I bumped into myself recently. There's an
> infinite supply of more of those where these came from.
>
>
> >
> >> I think many (if not all) of your proposals make sense, but most of them
> >> make sense as an opt-in - perhaps using something similar to Perl's
> strict
> >> mode (which incidentally, changes the way the language treats undefined
> >> variables in exactly the same way). This would also provide a
> future-proof
> >> solution for additional similarly-themed proposals (such as strict ops,
> >> etc.).
> >>
> >
> > I don't think this is an appropriate use of an opt-in. It's a case where
> > we can balance language cleanup with backwards compatibility concerns.
> Code
> > that works after this proposal will also work before it, and as such
> there
> > is no danger of ecosystem bifurcation that would need to be addressed by
> an
> > opt-in.
> >
>
> Calling this 'cleanup' is opinionated, and avoiding bifurcation by forcing
> that opinion on everyone isn't a very good solution for those who have
> other opinions. While the opinion that variables must not be used before
> being initialized is obviously a valid one - it is just that, one valid
> opinion - and there are others. PHP never took this opinion as an
> axiomatic requirement (and not because of register_globals) - instead, the
> intent was to have a default value for uninitialized variables - a
> consistent, documented behavior since the dawn of the language. Can this
> be problematic under certain situations? Absolutely. Can it be useful in
> other cases? Sure (which is why it's very common). A great deal of folks
> both rely on this behavior and *like *it. Those who don't (and there's
> plenty of those as well of course) - always had a reasonable solution of
> enabling E_STRICT and enforcing E_STRICT-compliant code. I still think
> that having a strict mode (which can encompass strict types, strict ops,
> stricter error behavior, etc.) makes a lot of sense and would arguably be a
> superior option for the many folks who prefer a stricter language - but
> there's simply no way we can change one of the most fundamental behaviors
> of the language and force it down people's throats - not only because it
> breaks compatibility, but because it breaks how many people are used to
> write their PHP code. Perl provided
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
However, I feel pretty strongly that converting any of these to > deprecations is not a good idea. While there's certainly different views on > this, I've seen it often enough deprecation warning are considered an even > lower error level than notices (imagine my surprise when PEAR stopped > working completely in PHP 8 because nobody ever saw the hundreds of > suppressed deprecations). We could throw a deprecation in addition, but I > think this will make the development experience really suck for anyone who > is not actively working on a migration right now (imagine seeing lots of > warnings/notices during development twice). > You got a very valid point here. As long as there is a clear migration path, albeit with user-land tools, I'll take it. > I think it would be better to register an error handler that matches the > cases that will throw and can then log those. I'd be happy to provide an > implementation if you think this would be useful for your use-case. Also > has the nice advantage that you can start using it right now and don't have > to wait until you upgrade to a release that has deprecations. > It would be great to have a package that reports all these cases, though we could try to craft something ourselves if this RFC is approved. Perhaps frameworks providing error handlers can add specific logging for these scenarios as well, saves you from putting more effort in this than required. Regards, Lynn van der Berg
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov wrote:
> On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>
>>
>>
>> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov
>> wrote:
>>
>>> Hi internals,
>>>
>>> I think it's time to take a look at our existing warnings & notices in
>>> the
>>> engine, and think about whether their current classification is still
>>> appropriate. Error conditions like "undefined variable" only generating a
>>> notice is really quite mind-boggling.
>>>
>>> I've prepared an RFC with some suggested classifications, though there's
>>> room for bikeshedding here...
>>>
>>> https://wiki.php.net/rfc/engine_warnings
>>
>>
>> Specifically on undefined variables, the way we deal with them has little
>> to do with register_globals. It's behavior you can find in other
>> dynamic languages (e.g. Perl), and allows for certain code patterns (which
>> rely on the automatic creation of a variable whenever it's used in write
>> context, and on a default known-in-advance value in case it's used in a
>> read context). It's fine not to like this behavior or the code patterns
>> that commonly rely on it (e.g., @$foo++), but it's intentional and isn't
>> related to any historical reasons.
>>
>
> This argument makes sense for arrays and objects (and I don't promote
> undefined index/property to exceptions for that reason), but I don't think
> it holds any water for simple variables. Writing @$counts[$key]++ is a lazy
> way to count values and avoid ugly boilerplate for if
> (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }.
> But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1.
> Outside of variable variables, the concept of a conditionally defined
> variable just doesn't make a lot of sense.
>
This example has nothing to do with arrays. There are many code patterns
in which relying on this behavior makes perfect sense for folks who are a
lot less strictly-minded. For example:
foreach (whatever) {
if (sth) {
@$whCount++;
}
}
Yes, it may be painful for many eyes that $whCount is not explicitly
initialized, but the above code is perfectly legitimate, warning-free
notice-compliant code since forever. Moreover - this isn't legacy - there
are a lot of folks who appreciate this precise behavior, which is
documented and works as expected for the last 20+ years.
Or:
if ($bookCount>0) {
$suffix = 's';
}
print "$bookCount book$suffix";
These are just two simple cases I bumped into myself recently. There's an
infinite supply of more of those where these came from.
>
>> I think many (if not all) of your proposals make sense, but most of them
>> make sense as an opt-in - perhaps using something similar to Perl's strict
>> mode (which incidentally, changes the way the language treats undefined
>> variables in exactly the same way). This would also provide a future-proof
>> solution for additional similarly-themed proposals (such as strict ops,
>> etc.).
>>
>
> I don't think this is an appropriate use of an opt-in. It's a case where
> we can balance language cleanup with backwards compatibility concerns. Code
> that works after this proposal will also work before it, and as such there
> is no danger of ecosystem bifurcation that would need to be addressed by an
> opt-in.
>
Calling this 'cleanup' is opinionated, and avoiding bifurcation by forcing
that opinion on everyone isn't a very good solution for those who have
other opinions. While the opinion that variables must not be used before
being initialized is obviously a valid one - it is just that, one valid
opinion - and there are others. PHP never took this opinion as an
axiomatic requirement (and not because of register_globals) - instead, the
intent was to have a default value for uninitialized variables - a
consistent, documented behavior since the dawn of the language. Can this
be problematic under certain situations? Absolutely. Can it be useful in
other cases? Sure (which is why it's very common). A great deal of folks
both rely on this behavior and *like *it. Those who don't (and there's
plenty of those as well of course) - always had a reasonable solution of
enabling E_STRICT and enforcing E_STRICT-compliant code. I still think
that having a strict mode (which can encompass strict types, strict ops,
stricter error behavior, etc.) makes a lot of sense and would arguably be a
superior option for the many folks who prefer a stricter language - but
there's simply no way we can change one of the most fundamental behaviors
of the language and force it down people's throats - not only because it
breaks compatibility, but because it breaks how many people are used to
write their PHP code. Perl provided stricter-liking folks with a solution
in the form of 'use strict;' decades ago; JS did something similar much
more recently. Neither of these created any sort of bifurcation - it's a
simple, sensible solution that has virtually no downsides.
Zeev
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, 28 Aug 2019 at 12:57, Nikita Popov wrote: > However, I feel pretty strongly that converting any of these to > deprecations is not a good idea. While there's certainly different views on > this, I've seen it often enough deprecation warning are considered an even > lower error level than notices (imagine my surprise when PEAR stopped > working completely in PHP 8 because nobody ever saw the hundreds of > suppressed deprecations). We could throw a deprecation in addition, but I > think this will make the development experience really suck for anyone who > is not actively working on a migration right now (imagine seeing lots of > warnings/notices during development twice). > Again, I considered this carefully for undefined constants and discussed it extensively on the RFC and resulting thread. In short, "deprecation notice" doesn't have to mean "E_DEPRECATED". Arguably, "severity" and "type" should be two different dimensions, and E_DEPRECATION_WARNING would be E_DEPRECATION & E_WARNING; but in practice, a Warning containing the text "this is deprecated" achieves the goal just fine. Whatever the mechanism, the point is to make people aware as far in advance as possible, so that they can start addressing the problem before it becomes a blocker to upgrading. As briefly mentioned, third-party libraries are a key case here: if a library raises extra Warnings, I can take the time to submit a patch to that library, wait for the maintainer to accept it, and make sure I can use the latest version; if the library raises extra Errors, I have to delay my upgrade, or run a patched version of the library, until it's fixed. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Am 28.08.2019 um 13:10 schrieb Nikita Popov :
> On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>> Specifically on undefined variables, the way we deal with them has little
>> to do with register_globals. It's behavior you can find in other dynamic
>> languages (e.g. Perl), and allows for certain code patterns (which rely on
>> the automatic creation of a variable whenever it's used in write context,
>> and on a default known-in-advance value in case it's used in a read
>> context). It's fine not to like this behavior or the code patterns that
>> commonly rely on it (e.g., @$foo++), but it's intentional and isn't related
>> to any historical reasons.
>
> This argument makes sense for arrays and objects (and I don't promote
> undefined index/property to exceptions for that reason), but I don't think
> it holds any water for simple variables. Writing @$counts[$key]++ is a lazy
> way to count values and avoid ugly boilerplate for if
> (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }.
> But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1.
> Outside of variable variables, the concept of a conditionally defined
> variable just doesn't make a lot of sense.
We often use the pattern $a .= "xy" or $a[] = "xy" and requiring to initialise
leads to either boiler-plate code in often very simple functions or even worse
to write the first one as $a = "xy" and $a = ["xy"] which both hurt symmetry
and extensibility (you need to change two places if you want to add a new first
entry). We are already suppressing the E_NOTICE for this as the pattern is too
useful to fill our logs.
Your simple typo in variable names can be caught well enough by a static
analyser, we have a simplistic one in out git commit hook which more than does
the job for us. And it does it even better in your average case as it also
catches typos in rare code paths not executed by your tests. And no, don't say
"make sure you have 100% code coverage", that is a myth.
Summary: Promote E_NOTICE to E_WARNINGS, fine, make them abort code execution:
Don't do it, don't break our code.
For people promoting a stricter PHP mode: Just fix your code if it caused an
E_NOTICE/E_WARNING, you don't need an Exception for that. And I don't buy the
whole security argument, code has to be secure on a whole different level than
undefined variables.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 1:46 PM Lynn wrote:
>
>
>
> This argument makes sense for arrays and objects (and I don't promote
>> undefined index/property to exceptions for that reason), but I don't think
>> it holds any water for simple variables. Writing @$counts[$key]++ is a
>> lazy
>> way to count values and avoid ugly boilerplate for if
>> (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }.
>> But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1.
>> Outside of variable variables, the concept of a conditionally defined
>> variable just doesn't make a lot of sense.
>>
>
> The variables are not conditionally declared on purpose, but as it's code
> written 15~20 years ago, maintained, copy-pasted over and over and never
> reviewed, there's a lot of issues that remain that my trigger an error
> exception if this proposal is passed without migration path.
>
To be clear, this was in response to Zeev's particular argument, which I
don't think is valid. I am aware that accesses to undefined variables are a
thing in legacy code.
However, I feel pretty strongly that converting any of these to
deprecations is not a good idea. While there's certainly different views on
this, I've seen it often enough deprecation warning are considered an even
lower error level than notices (imagine my surprise when PEAR stopped
working completely in PHP 8 because nobody ever saw the hundreds of
suppressed deprecations). We could throw a deprecation in addition, but I
think this will make the development experience really suck for anyone who
is not actively working on a migration right now (imagine seeing lots of
warnings/notices during development twice).
I think it would be better to register an error handler that matches the
cases that will throw and can then log those. I'd be happy to provide an
implementation if you think this would be useful for your use-case. Also
has the nice advantage that you can start using it right now and don't have
to wait until you upgrade to a release that has deprecations.
Nikita
>
> ```
> // a.php
> if ($someCondition) { // comes from another file, never used, can't verify
> existance
> $foo = 'foo';
> }
>
> // b.php
> $bar = 'bar';
>
> // scenario1.php
> include 'a.php'; // this would crash
> include 'b.php';
>
> echo $foo . $bar; // this would crash if the include didn't yet
>
> // scenario2.php
> $someCondition = true;
>
> include 'a.php'; // this would not crash
> include 'b.php';
>
> echo $foo . $bar; // this would not crash
> ```
>
> The problem with the above legacy code, which we sadly have spread through
> a spaghetti of thousands of files, is that if it starts throwing errors
> with no migration path, we simply can't update without spending possibly
> weeks debugging and trying to find scenarios where this might trigger. Now
> I'm not sure, but if I would've used `include_once` and combine this with
> function/class scopes (people loved to do that in our legacy code), all
> hell breaks loose and it will be nearly impossible to find the cases.
>
> All I'm asking is for a clear upgrade path with deprecations so that my
> code can be safely migrated over time, rather than have it crash with the
> next version. Compared to easy to fix. By having it throw deprecations which we can easily log to a
> specific file, we can gather and fix the cases when we have time to spend
> on technical debt, and by the time the warning will turn into an error
> exception, we'll have fixed probably 90%+ of the cases, making the upgrade
> possible.
>
> Regards,
> Lynn van der Berg
>
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
This argument makes sense for arrays and objects (and I don't promote
> undefined index/property to exceptions for that reason), but I don't think
> it holds any water for simple variables. Writing @$counts[$key]++ is a lazy
> way to count values and avoid ugly boilerplate for if
> (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }.
> But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1.
> Outside of variable variables, the concept of a conditionally defined
> variable just doesn't make a lot of sense.
>
The variables are not conditionally declared on purpose, but as it's code
written 15~20 years ago, maintained, copy-pasted over and over and never
reviewed, there's a lot of issues that remain that my trigger an error
exception if this proposal is passed without migration path.
```
// a.php
if ($someCondition) { // comes from another file, never used, can't verify
existance
$foo = 'foo';
}
// b.php
$bar = 'bar';
// scenario1.php
include 'a.php'; // this would crash
include 'b.php';
echo $foo . $bar; // this would crash if the include didn't yet
// scenario2.php
$someCondition = true;
include 'a.php'; // this would not crash
include 'b.php';
echo $foo . $bar; // this would not crash
```
The problem with the above legacy code, which we sadly have spread through
a spaghetti of thousands of files, is that if it starts throwing errors
with no migration path, we simply can't update without spending possibly
weeks debugging and trying to find scenarios where this might trigger. Now
I'm not sure, but if I would've used `include_once` and combine this with
function/class scopes (people loved to do that in our legacy code), all
hell breaks loose and it will be nearly impossible to find the cases.
All I'm asking is for a clear upgrade path with deprecations so that my
code can be safely migrated over time, rather than have it crash with the
next version. Compared to
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, 28 Aug 2019 at 10:33, Nikita Popov wrote: > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefined variable" only generating a > notice is really quite mind-boggling. > While I agree with the reasoning behind this, I think we should be very, very careful of promoting anything beyond Warning. While it's certainly true that bugs may be hiding behind Notices and Warnings, it's equally certain that there is code that is poorly written but has entirely correct behaviour; for such code, the cure will be worse than the disease, because an unhandled Error is like suddenly pulling the plug out of the server in the middle of a transaction. That's why I was very careful with my undefined constant RFC [1] to first raise the Notice to a Warning, and leave an appropriate period before raising to Error. I would be 100% behind raising undefined variable from Notice to Warning, but think the impact of raising to Error is high enough that it would risk delaying take-up of PHP 8. Is it too late to raise to Warning in 7.4, with a clear message that it will be an error in 8.0? That would give time for people to discover it in rare code paths, get changes pushed to third-party libraries, etc, before it becomes an unavoidable error. [1] https://wiki.php.net/rfc/deprecate-bareword-strings -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>
>
> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov
> wrote:
>
>> Hi internals,
>>
>> I think it's time to take a look at our existing warnings & notices in the
>> engine, and think about whether their current classification is still
>> appropriate. Error conditions like "undefined variable" only generating a
>> notice is really quite mind-boggling.
>>
>> I've prepared an RFC with some suggested classifications, though there's
>> room for bikeshedding here...
>>
>> https://wiki.php.net/rfc/engine_warnings
>
>
> Specifically on undefined variables, the way we deal with them has little
> to do with register_globals. It's behavior you can find in other dynamic
> languages (e.g. Perl), and allows for certain code patterns (which rely on
> the automatic creation of a variable whenever it's used in write context,
> and on a default known-in-advance value in case it's used in a read
> context). It's fine not to like this behavior or the code patterns that
> commonly rely on it (e.g., @$foo++), but it's intentional and isn't related
> to any historical reasons.
>
This argument makes sense for arrays and objects (and I don't promote
undefined index/property to exceptions for that reason), but I don't think
it holds any water for simple variables. Writing @$counts[$key]++ is a lazy
way to count values and avoid ugly boilerplate for if
(isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }.
But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1.
Outside of variable variables, the concept of a conditionally defined
variable just doesn't make a lot of sense.
> I think many (if not all) of your proposals make sense, but most of them
> make sense as an opt-in - perhaps using something similar to Perl's strict
> mode (which incidentally, changes the way the language treats undefined
> variables in exactly the same way). This would also provide a future-proof
> solution for additional similarly-themed proposals (such as strict ops,
> etc.).
>
I don't think this is an appropriate use of an opt-in. It's a case where we
can balance language cleanup with backwards compatibility concerns. Code
that works after this proposal will also work before it, and as such there
is no danger of ecosystem bifurcation that would need to be addressed by an
opt-in.
Thanks,
Nikita
[PHP-DEV] Re: [RFC] Reclassifying engine warnings
On 28/08/2019 10:33, Nikita Popov wrote: Hi internals, https://wiki.php.net/rfc/engine_warnings This is an absolutely outstanding move and I certainly hope it gets passed unanimously. PHP as a whole has traditionally been a language that is insanely forgiving of errors, in many cases allowing code execution to continue as if they never even happened, even in utterly egregious cases, and that is certainly something that has played a part in PHP's reputational difficulties. I am extremely happy to see this and other changes underway to reverse these historic failings. It can only be a good thing for the PHP ecosystem as a whole to have the engine and core extensions enforce better protections against bad or potentially buggy code. It won't be an instant transition, and there will be a lot of hold-outs on 7.4 who just don't want to deal with it, but as people do eventually migrate to 8.0, this error-throwing behaviour will force programmers to improve their code rather than just consign the problem to the /dev/null error log. These changes are, no doubt, going to be a painful wake up call for our friends in the community who are, shall we say, not as focused on the quality of their code as we (and their customers) would perhaps like them to be. For everyone else, it's one more tool to help make us aware of problems, and prevent those problems from propagating along the stack and effecting other things. Bring it on. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov wrote: > Hi internals, > > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefined variable" only generating a > notice is really quite mind-boggling. > > I've prepared an RFC with some suggested classifications, though there's > room for bikeshedding here... > > https://wiki.php.net/rfc/engine_warnings Specifically on undefined variables, the way we deal with them has little to do with register_globals. It's behavior you can find in other dynamic languages (e.g. Perl), and allows for certain code patterns (which rely on the automatic creation of a variable whenever it's used in write context, and on a default known-in-advance value in case it's used in a read context). It's fine not to like this behavior or the code patterns that commonly rely on it (e.g., @$foo++), but it's intentional and isn't related to any historical reasons. I think many (if not all) of your proposals make sense, but most of them make sense as an opt-in - perhaps using something similar to Perl's strict mode (which incidentally, changes the way the language treats undefined variables in exactly the same way). This would also provide a future-proof solution for additional similarly-themed proposals (such as strict ops, etc.). Zeev
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Hi Nikita, This RFC makes me very happy! I have a few points that I didn't find clarification on in the RFC. For "Undefined variable: %s" the new proposal is an Error Exception. For a starter: will it include dynamically declared variables such as $$foo? For my second point: in regards of backwards compatibility, is it possible to first trigger a deprecation for each of the cases that will abort the flow? If not, I fear I won't be able to upgrade as we still maintain a lot of legacy code that deals with dynamically declared and undefined variables, and possibly other violations that we don't know of. We are working on rewriting all this code but don't have enough developers to rewrite everything under a few years. If we can start logging these deprecations, we know where to fix what, rather than having our entire application crash. This way we can prioritize our maintenance on fixes each of these cases. The scenarios where this occurs often in our code base are dynamically included files that may or may not set a variable. The code is most likely "broken", but the behavior it produces is what's considered correct at this point. It can be solved by defining the variable with null value, but it's hard to trace without logging as we can't always set it with null value. Regards, Lynn van der Berg On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: > Hi internals, > > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefined variable" only generating a > notice is really quite mind-boggling. > > I've prepared an RFC with some suggested classifications, though there's > room for bikeshedding here... > > https://wiki.php.net/rfc/engine_warnings > > Regards, > Nikita >
[PHP-DEV] [RFC] Reclassifying engine warnings
Hi internals, I think it's time to take a look at our existing warnings & notices in the engine, and think about whether their current classification is still appropriate. Error conditions like "undefined variable" only generating a notice is really quite mind-boggling. I've prepared an RFC with some suggested classifications, though there's room for bikeshedding here... https://wiki.php.net/rfc/engine_warnings Regards, Nikita
