Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-14 Thread Olumide Samson
https://jaxenter.com/php-tiobe-sept-2019-162096.html I think this is one of those things we get from voting no... I might be wrong anyways :-? On Sat, Sep 14, 2019, 12:43 AM Kosit Supanyo wrote: > Hi internals > > This maybe a little bit late but I would like to propose alternative to > this

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-13 Thread Kosit Supanyo
Hi internals This maybe a little bit late but I would like to propose alternative to this RFC. What if we add `strict_errors` declare to make every function/method in files that declared `strict_errors` throw ErrorException on Notice/Warning. Example: File: Test.php

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-13 Thread Robert Korulczyk
> $foo[$key1] has to be read to determine if it's already an array, and if it > has the key $key2, in the same way that in $foo[$key1]++, $foo[$key1] has > to be read to determine if it's already an integer and what it's value is. $foo[$key1] needs to be read only to obtain previous value, type

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-13 Thread Rowan Tommins
On 13/09/2019 10:02, Robert Korulczyk wrote: Why? If "assume $key2 exists as a key and is an integer" is so bad that PHP should halt my program, why should "assume $key1 exists and is an array" be perfectly OK? Warning is triggered by reading non-existing key, not assigning value to it. In

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-13 Thread Robert Korulczyk
> Why? If "assume $key2 exists as a key and is an integer" is so bad that PHP > should halt my program, why should "assume $key1 exists and is an array" > be perfectly OK? Warning is triggered by reading non-existing key, not assigning value to it. In `$foo[$key1][$key2] ??= 0` you never try to

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-13 Thread Rowan Tommins
On 13/09/2019 09:01, Robert Korulczyk wrote: Actually you need only one additional line: $foo = []; foreach ( $something as $key1 ) { foreach ( $somethingElse as $key2 ) { $foo[$key1][$key2] ??= 0; $foo[$key1][$key2]++; } } Why? If "assume $key2 exists as a

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-13 Thread Rowan Tommins
On 12/09/2019 22:56, Andreas Hennings wrote: $var[$k0][? $k1][? $k2]++; This is great but the second "?" is redundant isn't it? If the rule is "you cannot read a non-existent array element without ?" then no: $var[$k0][? $k1] allows you to read that element, and from context treat it as an

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-13 Thread Robert Korulczyk
W dniu 12.09.2019 o 22:45, Rowan Tommins pisze: > On 12/09/2019 15:43, Robert Korulczyk wrote: >> One additional line will make your code much more obvious and easier to read >> and understand: >> >> $i ??= 0; >> $i++; > > > I don't find this code at all obvious: > > foreach ( $something as

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Arnold Daniels
l want to point out that way in which notices and warnings are triggered when concerning operators, is also inconsistent. Sometimes a check is done by the function of the operator (or a deeper function). Other times the operator will simply cast the operand and the casting produces a notice,

[PHP-DEV] Syntax Sugar (was [PHP-DEV] [RFC] Reclassifying engine warnings)

2019-09-12 Thread Mike Schinkel
> One thing I like PHP for is a distinct lack of huge amounts of syntax > sugar. Take Ruby - it's a hell to read the code. I think it is unfair to reference Ruby's capabilities as a counter-example for syntax sugar. The Ruby language allows developers to create what are effectively new

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Andreas Hennings
In the past I suggested operators like ??++ ??+= for this purpose. But the [? $key] is even better, because it makes it explicit which array keys we expect to already exist and which we don't. $var[$k0][? $k1][? $k2]++; This is great but the second "?" is redundant isn't it? Marco Pivetta

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Stanislav Malyshev
Hi! > FTR this is basically what Python does via defaultdict: > https://docs.python.org/3/library/collections.html#collections.defaultdict > > I think it is the "cleanest" solution to this problem overall. Though it > does need a separate structure, rather than our favorite PHP array. This is

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Rowan Tommins
On 12/09/2019 15:13, Nikita Popov wrote: FTR this is basically what Python does via defaultdict: https://docs.python.org/3/library/collections.html#collections.defaultdict Thanks, I'm glad I wasn't completely daft thinking there might be some way to express it. :) I think it is the

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Rowan Tommins
On 12/09/2019 15:43, Robert Korulczyk wrote: One additional line will make your code much more obvious and easier to read and understand: $i ??= 0; $i++; I don't find this code at all obvious: foreach ( $something as $foo ) {     $i ??= 0;     $i++; } I mean, huh? What's that zero doing

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
On Thu, Sep 12, 2019 at 10:43 AM Robert Korulczyk wrote: > > But, if you're dealing with a counter, then, the intent is that you are > > going to start counting at 0 and increase it. > > This is not that clear as you may think. Several questions may come to > mind when you will see

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Robert Korulczyk
> But, if you're dealing with a counter, then, the intent is that you are > going to start counting at 0 and increase it. This is not that clear as you may think. Several questions may come to mind when you will see incrementation of non-existing variable/key. Is it a bug and this should be

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
On Thu, Sep 12, 2019 at 10:20 AM Reindl Harald (privat) wrote: > see screenshot, you are the only guy on planet earth whose fukcing first > line is part of the quote above > If you're going to reply to me off list, please at least be polite. -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Marco Pivetta
On Thu, Sep 12, 2019 at 4:02 PM Arvids Godjuks wrote: > > > чт, 12 сент. 2019 г. в 15:33, Marco Pivetta : > >> Hey Rowan, >> >> >> >> On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins >> wrote: >> >> > For instance, for undefined array

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
On Thu, Sep 12, 2019 at 10:11 AM Rowan Tommins wrote: > On Thu, 12 Sep 2019 at 14:55, Claude Pache wrote: > > > Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > > > Marco Pivetta > > > > > > That violates blatantly DRY (twice the

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Nikita Popov
On Thu, Sep 12, 2019 at 4:11 PM Rowan Tommins wrote: > On Thu, 12 Sep 2019 at 14:55, Claude Pache wrote: > > > Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > > > Marco Pivetta > > > > > > That violates blatantly DRY (twice the

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Rowan Tommins
On Thu, 12 Sep 2019 at 15:02, Arvids Godjuks wrote: > > This message contains a healthy dose of sarcasm. > I think we need less sarcasm on this thread, and more empathy. I'm doing my best to discuss a real scenario, and how to improve the language for it, and move away from oh-so-hilarious

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Benjamin Morel
>> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > That violates blatantly DRY (twice the exact same lengthy expression `$foo[$key1][$key2]`), so it is not a satisfactory solution. $foo[$key1][$key2]??++  More seriously, yes as Marco suggested, yes we can already do it, and as Claude

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
On Thu, Sep 12, 2019 at 10:06 AM Arvids Godjuks wrote: > > > чт, 12 сент. 2019 г. в 16:02, Chase Peeler : > >> On Thu, Sep 12, 2019 at 9:55 AM Claude Pache >> wrote: >> >> > >> > >> > > Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit >> : >> > > >> > > $foo[$key1][$key2] = ($foo[$key1][$key2]

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Rowan Tommins
On Thu, 12 Sep 2019 at 14:55, Claude Pache wrote: > Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > Marco Pivetta > > > That violates blatantly DRY (twice the exact same lengthy expression > `$foo[$key1][$key2]`), so it is not a

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
On Thu, Sep 12, 2019 at 10:02 AM Arvids Godjuks wrote: > чт, 12 сент. 2019 г. в 15:33, Marco Pivetta : > > > Hey Rowan, > > > > > > > > On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins > > wrote: > > > > > For instance, for undefined array keys, what if we had an

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Arvids Godjuks
чт, 12 сент. 2019 г. в 16:02, Chase Peeler : > On Thu, Sep 12, 2019 at 9:55 AM Claude Pache > wrote: > > > > > > > > Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > > > > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > > > > > Marco Pivetta > > > > That violates blatantly DRY

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Arvids Godjuks
чт, 12 сент. 2019 г. в 15:33, Marco Pivetta : > Hey Rowan, > > > > On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins > wrote: > > > For instance, for undefined array keys, what if we had an operator for > > "initialise and retrieve", such as $foo[? 'bar']. Then we could

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
On Thu, Sep 12, 2019 at 9:55 AM Claude Pache wrote: > > > > Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > > > Marco Pivetta > > That violates blatantly DRY (twice the exact same lengthy expression > `$foo[$key1][$key2]`), so it

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Claude Pache
> Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > Marco Pivetta That violates blatantly DRY (twice the exact same lengthy expression `$foo[$key1][$key2]`), so it is not a satisfactory solution. —Claude

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
On Thu, Sep 12, 2019 at 5:41 AM Claude Pache wrote: > > > > Le 12 sept. 2019 à 10:17, Stephen Reay a > écrit : > > > > > > > > I’ve seen a number of people that have concerns about PHP throwing > actual errors (as opposed to notices) because they try to use a > variable/offset that doesn’t

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Marco Pivetta
Hey Rowan, On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins wrote: > For instance, for undefined array keys, what if we had an operator for > "initialise and retrieve", such as $foo[? 'bar']. Then we could simplify > ugly code like this: > > if ( ! isset($foo[$key1])

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Rowan Tommins
On Thu, 12 Sep 2019 at 11:32, Benjamin Morel wrote: > I don't think there are that many such *potentially *legitimate use cases, > so maybe we could just list the use cases and think about a more elegant > solution to solve them? > Yes, please. If we can focus less on vague anecdotes and

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Rowan Tommins
On Thu, 12 Sep 2019 at 12:32, Arvids Godjuks wrote: > Every single workplace I worked in past 5 years always had 0 tolerance > policy for all notices, warnings and E_STRICT. > Well, that's fine then, you don't need this change. It will make zero difference to you whether something is

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Arvids Godjuks
чт, 12 сент. 2019 г. в 12:32, Benjamin Morel : > > > > For example when I’m writing a throw-away script, some notices are okay > to > > indicate possible problems > > > Maybe it's just me, but even in throw-away scripts, *I've lost much more > time because of warnings/notices going unnoticed,

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Benjamin Morel
> > For example when I’m writing a throw-away script, some notices are okay to > indicate possible problems Maybe it's just me, but even in throw-away scripts, *I've lost much more time because of warnings/notices going unnoticed, than I've saved thanks to PHP's forgiving nature*. Hence even in

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Claude Pache
> Le 12 sept. 2019 à 10:17, Stephen Reay a écrit : > > > > I’ve seen a number of people that have concerns about PHP throwing actual > errors (as opposed to notices) because they try to use a variable/offset that > doesn’t exist, and of course there is often a proposal to have a declare

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Nikita Popov
On Thu, Sep 12, 2019 at 9:40 AM Claude Pache wrote: > > Le 10 sept. 2019 à 15:31, Nikita Popov a écrit : > > > > 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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Benjamin Morel
> > declare(sloppy=1); I like this idea. Strict by default, sloppy by (code-level) config.

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Stephen Reay
> On 12 Sep 2019, at 14:40, Claude Pache wrote: > >> Le 10 sept. 2019 à 15:31, Nikita Popov a écrit : >> >> 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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Claude Pache
> Le 10 sept. 2019 à 15:31, Nikita Popov a écrit : > > 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 >>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-02 Thread Arvids Godjuks
On Mon, Sep 2, 2019, 19:02 Sara Golemon wrote: > On Thu, Aug 29, 2019 at 2:29 PM Stanislav Malyshev > wrote: > > > >> I knew it worked, but I always considered this to basically be > > >> the PHP equivalent of undefined behavior in C. And I don't think > anyone > > > > It's not. It's very well

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-02 Thread Sara Golemon
On Thu, Aug 29, 2019 at 2:29 PM Stanislav Malyshev wrote: > >> I knew it worked, but I always considered this to basically be > >> the PHP equivalent of undefined behavior in C. And I don't think anyone > > It's not. It's very well defined behavior, that is not going to break - > unless it is

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-01 Thread Andreas Hennings
I think we should distinguish two separate problems in the discussion: 1. Undeclared local variables in function scope. Some poeple here think this "lazy" way of coding is actually more productive. Fixing such places would be straightforward.. except that it may require patching some legacy 3rd

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-30 Thread Thomas Bley
That's a good point, maybe a compromise is this: Matthew Brown hat am 28. August 2019 um 18:21 > geschrieben: > > > 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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Theodore Brown
On Wed, Aug 28, 2019 at 4: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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Stanislav Malyshev
Hi! >> encountered a PHP developer who thought using uninitialized variables >> was fine. > > Now you have. Nice to meet you. And there are more of us. You learn something new every day! >> I knew it worked, but I always considered this to basically be >> the PHP equivalent of undefined

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Christian Schneider
Am 29.08.2019 um 18:25 schrieb Aegir Leet : > Before reading the responses to this thread, I had honestly never > encountered a PHP developer who thought using uninitialized variables > was fine. Now you have. Nice to meet you. > I knew it worked, but I always considered this to basically be >

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Claude Pache
> Le 29 août 2019 à 18:25, Aegir Leet a écrit : > > Either way, if you want a less strict language, that language already > exists: It's the current version of PHP and you and everyone else who > likes the way it works can keep using it. > Meanwhile, I think most people currently doing serious

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Claude Pache
> Le 29 août 2019 à 18:13, Matthew Brown a écrit : > > I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used > today mostly as its architect intended at its founding. PHP, having > transitioned from a templating system to a fully-fledged language, is used > quite

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Todd Ruth
> From: Aegir Leet > Either way, if you want a less strict language, that language already > exists: It's the current version of PHP and you and everyone else who > likes the way it works can keep using it. For approximately 3 years. Please remember "end of life". We'd still be using php5

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Aegir Leet
Before reading the responses to this thread, I had honestly never encountered a PHP developer who thought using uninitialized variables was fine. I knew it worked, but I always considered this to basically be the PHP equivalent of undefined behavior in C. And I don't think anyone would get mad if

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Matthew Brown
I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used today mostly as its architect intended at its founding. PHP, having transitioned from a templating system to a fully-fledged language, is used quite differently. > On Aug 29, 2019, at 11:50 AM, Chase Peeler wrote: >

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Chase Peeler
On Thu, Aug 29, 2019 at 10:22 AM Zeev Suraski wrote: > On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals < > internals@lists.php.net> wrote: > > > I know what the manual says about notices. But I don't agree with > > interpreting "could happen in the normal course of running a script" as

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Zeev Suraski
On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals < internals@lists.php.net> wrote: > I know what the manual says about notices. But I don't agree with > interpreting "could happen in the normal course of running a script" as > "it's perfectly fine if this part of your code triggers a

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Aegir Leet via internals
I know what the manual says about notices. But I don't agree with interpreting "could happen in the normal course of running a script" as "it's perfectly fine if this part of your code triggers a notice consistently and every time it goes down this particular code path". Rather, I've always

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Claude Pache
> Le 29 août 2019 à 13:33, Aegir Leet via internals a > écrit : > > I'm sorry, but if you seriously believe doing something that generates a > notice (or warning, or error, ...) is not a bug - you're delusional. No, what you think is not at all how notices were designed. From the manual

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Peter Bowyer
On Thu, 29 Aug 2019 at 08:28, Christian Schneider wrote: > Side-note: Which brings us back to the discussion about the downsides of > language modes but as similar topics keep on popping up (although by the > same people) you are slowly convincing me that going down that road is the > best

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Christian Schneider
Am 29.08.2019 um 08:22 schrieb Alexandru Pătrănescu : > When you write code, in a "productive" way that you mention, it's perfectly > fine if you write it for you and for now. > > But most often, we write code for the future generations of developers that > could be less skilled, for the future

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Alexandru Pătrănescu
Zeev, When you write code, in a "productive" way that you mention, it's perfectly fine if you write it for you and for now. But most often, we write code for the future generations of developers that could be less skilled, for the future you that might have less context. Also, code will evolve

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Zeev Suraski
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*

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stephen Reay
> 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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Olumide Samson
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; > >

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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,

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
$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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Todd Ruth
> 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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Mark Randall
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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 || {};

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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.

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Philip Hofstetter
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Stanislav Malyshev
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Rowan Collins
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Zeev Suraski
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Olumide Samson
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Rowan Collins
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
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

RE: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Reinis Rozitis
> "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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Rowan Collins
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Zeev Suraski
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Marco Pivetta
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Rowan Collins
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Matthew Brown
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Mark Randall
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Arvids Godjuks
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Thomas Bley
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

  1   2   >