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

[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 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
>  declare(strict_errors=1); // does not support block declare like
> 'strict_type'
>
> class Test {
> public function __construct()
> {
> echo $a; // ErrorException will be thrown from here
> }
> }
>
> File: main.php
>  require 'Test.php';
> $test = new Test(); // Fatal error: Uncaught ErrorException: Undefined
> variable: a
>
> But if `set_error_handler()` is in use nothing will happen.
>
> File: main.php
>  require 'Test.php';
> set_error_handler(function () {
>
> });
> $test = new Test(); // silent
>
> I've just made a naive implementation to demonstrate this approach at
> https://github.com/webdevxp/php-src.
> What I've done was just adding new ZEND_ACC_STRICT_ERRORS flag to top level
> function and modified `php_error_cb` to check if there is a caller with
> `strict_errors` defined. (by simply checking `EG(current_execute_data)` and
> its all `prev_execute_data`)
>
> I think this approach might satify both 'strict camp' and 'bc camp'.
>
> P.S. I myself agree with this RFC and would vote YES if I can vote. And I'm
> grateful for Nikita's (and others) contributions that make PHP awesome
> today.
>
> Cheers :)
>
> On Wed, Aug 28, 2019 at 4: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
> >
> > Regards,
> > Nikita
> >
>

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

[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
https://github.com/webdevxp/php-src.
What I've done was just adding new ZEND_ACC_STRICT_ERRORS flag to top level
function and modified `php_error_cb` to check if there is a caller with
`strict_errors` defined. (by simply checking `EG(current_execute_data)` and
its all `prev_execute_data`)

I think this approach might satify both 'strict camp' and 'bc camp'.

P.S. I myself agree with this RFC and would vote YES if I can vote. And I'm
grateful for Nikita's (and others) contributions that make PHP awesome
today.

Cheers :)

On Wed, Aug 28, 2019 at 4: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
>
> Regards,
> Nikita
>

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

[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 is irrelevant 
(obviously you will get error if types does not allow for such
operation, but it has nothing to do with accessing uninitialized 
variables/keys). You can't increment $foo[$key1] without knowing current value 
of
$foo[$key1] - you need to read it first. But you don't need to know previous 
value (or its type) to overwrite it (it does not matter what is
$foo[$key1] value if you do `$foo[$key1] = 1` - it works similar to `$foo = 1`);



Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 
`$foo[$key1][$key2] ??= 0` you never try to read non-existing key.



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

If we're talking about being strict, we shouldn't limit ourselves to what 
happens to give a warning today, we should be consistent in our reasoning. So 
if the reasoning is that accessing uninitialised array keys is dangerous, I 
should not be able to mention $foo[$key1][$key2] if $foo[$key1] doesn't yet 
exist.

Regards,

--
Rowan Tommins (né 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

[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 read non-existing key.

> Please can you show me a bug that adding this line has avoided? I don't doubt 
> that the same warning saves bugs in other scenarios, but in this
> scenario, the logic is unambiguous, and any additions are just to suppress 
> unnecessary errors.

Well, then let's say that it is "lesser evil" - one additional line is better 
than ignoring reading uninitialized values. And IMO it is not a
"problem" that would justify introducing special syntax for saving one line in 
such niche case.



Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 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?




It does not look confusing. You have two lines, for two intents - start 
counting from zero and increment counter on every loop iteration.



There is no intent to start counting at zero; the counter will never be 
lower than 1. If we really wanted to express the intent, we would have 
to write something like this:



$foo[$key1] ??= [];
if ( ! isset($foo[$key1][$key2]) ) {
   $foo[$key1][$key2] = 1;
}
else {
   $foo[$key1][$key2]++;
}



If one additional line is to much for making your code less ambiguous and more 
bug-free, then I won't even try to change your mind.



Please can you show me a bug that adding this line has avoided? I don't 
doubt that the same warning saves bugs in other scenarios, but in this 
scenario, the logic is unambiguous, and any additions are just to 
suppress unnecessary errors.


To reiterate, my motivation here is to discuss features that help write 
these scenarios with less boilerplate, and separate them from other 
scenarios where there's a real bug risk which should raise an error.



Regards,

--
Rowan Tommins (né 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

[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 array; but that array won't have a key $k2, so 
you also need to say that reading *that* was deliberate, and from 
context treat it as an integer.



Regards,

--
Rowan Tommins (né 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

[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 $foo ) {
>     $i ??= 0;
>     $i++;
> }


That is because it does not make sense. You should initialize $i before loop, 
since it does not need a loop at all (and you probably don't need ??= here):

$i ??= 0;
foreach ( $something as $foo ) {
$i++;
}

> Even using ??= the initialise-everything-before-use version looks like this:
> 
> $foo = [];
> foreach ( $something as $key1 ) {
>     foreach ( $somethingElse as $key2 ) {
>   $foo[$key1] ??= [];
>   $foo[$key1][$key2] ??= 0;
>   $foo[$key1][$key2]++;
>     }
> }

Actually you need only one additional line:

$foo = [];
foreach ( $something as $key1 ) {
foreach ( $somethingElse as $key2 ) {
  $foo[$key1][$key2] ??= 0;
  $foo[$key1][$key2]++;
}
}

> Again, the values are confusing: the end result will never contain an empty 
> array at the first level, and will never contain a 0 at the second level.

It does not look confusing. You have two lines, for two intents - start 
counting from zero and increment counter on every loop iteration. If one
additional line is to much for making your code less ambiguous and more 
bug-free, then I won't even try to change your mind.


Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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, warning or error.

As an example; The concatenation operator will implicitly cast anything to
a string. Explicitly casting it has no effect

[ ] . 'abc'; // Notice:  Array to string conversion
(string)[ ] . 'abc'; // Notice:  Array to string conversion

But arithmetic operators will do a check. Explicitly casting will remove
any warning or error

[ ] * 10; // Fatal error:  Unsupported operand types
(int)[ ] * 10; // 0
"22 bikes" * 10; // Notice:  A non well formed numeric value encountered
(int)"22 bikes" * 10; // 220

To some extent, the inconsistent error levels come from a different
approach. Even more, there is a big difference between types that can are
cast silently to a non-sensical value and types where any type of warning
or error is given, for seemingly no apparent reason.

Changing the warning levels without addressing this issue doesn't make a
whole lot of sense.

- Arnold
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?
Tekst uit oorspronkelijke berichten weergeven

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

[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  schrieb am Do., 12. Sep. 2019, 16:26:

>  
>
>
> 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 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]) {
> >> >$foo[$key1] = [];
> >> > }
> >> > if ( ! isset($foo[$key1][$key2]) {
> >> >$foo[$key1][$key2] = 0;
> >> > }
> >> > $foo[$key1][$key2]++;
> >> >
> >> >
> >> > With something safe but succinct like this:
> >> >
> >> > $foo[? $key1][? $key2]++;
> >> >
> >>
> >> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> >>
> >>
> >>
> > This message contains a healthy dose of sarcasm.
> >
> >
> No sarcasm intended: question is about the verbosity and length of a
> *proper* (correct = no warnings/notices/errors, matches type expectations)
> checked solution, and I provided a simple one-liner that is both readable
> and correct.
>
> You can make what you want out of this, but there was most certainly no
> sarcasm.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

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

[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 one of the most annoying quirks of python - that you have to use
special package to do simplest tasks like counting anything by key or
write annoying boilerplate code that reminds python that counting starts
with 0. Now strictness zealots want to bring that into PHP. If I was a
person to do that, I'd definitely write a long "python sadness" text and
that would feature there prominently, but I don't have time to do that
so I just note that now, that it is very sad that the annoying quirks of
python are brought into php apparently because more strict is always
better.

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

[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 "cleanest" solution to this problem overall. Though 
it does need a separate structure, rather than our favorite PHP array.



Indeed it does, and I think that's the better route to making PHP a 
stricter language: before we take away the existing features, add the 
new ones that let you express things better.


PHP's array type, and its type system in general, allow a lot of very 
expressive algorithms which are hard to do with more rigid type systems. 
Modern languages like C# bring back that expressiveness using things 
like generics, a rich library of built-in collections and interfaces, 
and so on; they don't just say "sorry, you can't do that".


Regards,

--
Rowan Tommins (né 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

[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 there, is it resetting the variable 
every loop?


Now, in that simple case, you can and probably should initialise the 
counter before the loop:


$i=0;
foreach ( $something as $foo ) {
    $i++;
}


But that's not the example I gave earlier! The example I gave earlier 
was a multi-dimensional array:


$foo = [];
foreach ( $something as $key1 ) {
    foreach ( $somethingElse as $key2 ) {
  $foo[$key1][$key2]++;
    }
}

Even using ??= the initialise-everything-before-use version looks like this:

$foo = [];
foreach ( $something as $key1 ) {
    foreach ( $somethingElse as $key2 ) {
  $foo[$key1] ??= [];
  $foo[$key1][$key2] ??= 0;
  $foo[$key1][$key2]++;
    }
}


Again, the values are confusing: the end result will never contain an 
empty array at the first level, and will never contain a 0 at the second 
level.


Those two lines aren't aiding the readability of that algorithm in any 
way; I have to read past them to find the actual business of the loop, 
which is counting something, using the ++ operator.


What's more, they're not preventing any bugs either! If I accidentally 
reuse $foo from a previous loop, the extra lines won't reinitialise 
anything for me; if I initialise it to empty, the two loops are 
functionally identical.



So that's where I came up with two suggestions to actually add to the 
language, rather than just taking away:


- a more granular way to express that this code is not actually 
error-prone, combining the 3 lines back into one
- or, a way to express the intent of the code more clearly, such as 
declaring the shape of an array



Regards,

--
Rowan Tommins (né 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

[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 incrementation of non-existing variable/key. Is it a
> bug
> and this should be initialized with a different value than 0? Maybe a
> mistake on copy? Maybe a typo?
>
> One additional line will make your code much more obvious and easier to
> read and understand:
>
> $i ??= 0;
> $i++;
>

And I'm totally in favor of writing code that way. What I'm not in favor of
is breaking all of the existing code that doesn't do it that way and works
perfectly fine because some people want to FORCE everyone to write it that
way.


> Your code is not only for compiler/parser, but also for humans. Expressing
> your intentions clearly is important - the less ambiguity the better.
>
> Regards,
> Robert Korulczyk
>


-- 
Chase Peeler
chasepee...@gmail.com

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

[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 initialized with a different value than 0? Maybe a mistake 
on copy? Maybe a typo?

One additional line will make your code much more obvious and easier to read 
and understand:

$i ??= 0;
$i++;

Your code is not only for compiler/parser, but also for humans. Expressing your 
intentions clearly is important - the less ambiguity the better.

Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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

[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 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]) {
>> >$foo[$key1] = [];
>> > }
>> > if ( ! isset($foo[$key1][$key2]) {
>> >$foo[$key1][$key2] = 0;
>> > }
>> > $foo[$key1][$key2]++;
>> >
>> >
>> > With something safe but succinct like this:
>> >
>> > $foo[? $key1][? $key2]++;
>> >
>>
>> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
>>
>>
>>
> This message contains a healthy dose of sarcasm.
>
>
No sarcasm intended: question is about the verbosity and length of a
*proper* (correct = no warnings/notices/errors, matches type expectations)
checked solution, and I provided a simple one-liner that is both readable
and correct.

You can make what you want out of this, but there was most certainly no
sarcasm.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

[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 exact same lengthy expression
> > `$foo[$key1][$key2]`), so it is not a satisfactory solution.
> >
>
>
> Agreed; it's certainly neater than all the isset() checks, but it's
> definitely a bit ugly.
>
> To clarify my point, the reason why people write this:
>
> $foo[$key1][$key2]++;
>
> Is not because they're lazy, it's because *it expresses their intent*.
>
> The ?key syntax was one suggestion for how to express the intent safely in
> that particular scenario. Another way might be that the array is
> initialised a different way; completely off the top of my head, something
> like this:
>
> $foo = new Dictionary>;
>
> That could express the intent of "this variable is going to be used as an
> accumulator with these dimensions".
>
> The "if isset" lines, in my opinion, don't express any intent, and they
> don't protect against any real errors; they're just noise to work around a
> short-coming in the language.
>
> But, if you're dealing with a counter, then, the intent is that you are
going to start counting at 0 and increase it. In that case, if the variable
hasn't be initialized, or, the array key doesn't exist, it makes sense to
assume it's 0.

If you need to do something else besides assuming it's 0 and counting from
there, then put in the extra code to check for that.
I can do this already:
if(!isset($i)){
  return false;
}
$i++;

So, why should I start having to do
if(!isset($i)){
  $i = 0;
}
$i++;

when
$i++;

works just fine.


> Regards,
> --
> Rowan Tommins
> [IMSoP]
>


-- 
Chase Peeler
chasepee...@gmail.com

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

[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 exact same lengthy expression
> > `$foo[$key1][$key2]`), so it is not a satisfactory solution.
> >
>
>
> Agreed; it's certainly neater than all the isset() checks, but it's
> definitely a bit ugly.
>
> To clarify my point, the reason why people write this:
>
> $foo[$key1][$key2]++;
>
> Is not because they're lazy, it's because *it expresses their intent*.
>
> The ?key syntax was one suggestion for how to express the intent safely in
> that particular scenario. Another way might be that the array is
> initialised a different way; completely off the top of my head, something
> like this:
>
> $foo = new Dictionary>;
>
> That could express the intent of "this variable is going to be used as an
> accumulator with these dimensions".
>
> The "if isset" lines, in my opinion, don't express any intent, and they
> don't protect against any real errors; they're just noise to work around a
> short-coming in the language.


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.

Nikita

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

[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 parodies of each other's positions.

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[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 pointed out, yes that's verbose.

What I had in mind with language support is some kind of code-level (per
line or block) switch that would allow uninitialized array keys to behave
in a certain way, *depending on the context* : we actually have not one,
but two good examples of this above, provided that $key1 and $key2 do not
exist:

- with [], an unitialized key would be initialized with an empty array
(already does that)
- with ++, an unitialized key would be initialized with 0

Without the proper code-level switch, we could safely have both cases above
throw an exception.

— Benjamin

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

[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] ?? 0) + 1;
>> > >
>> > > Marco Pivetta
>> >
>> > That violates blatantly DRY (twice the exact same lengthy expression
>> > `$foo[$key1][$key2]`), so it is not a satisfactory solution.
>> >
>> > And that's why PHP is so awesome. You don't have to do all these stupid
>> tricks just to do something simple like increment a counter. But, it looks
>> like we're going to throw that out of the window because some people think
>> that since they like doing it like the way above, everyone should have to.
>>
>> > —Claude
>> >
>> >
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>
> Easy, because experience shows that leads to bugs and lots of them.
> Security issues even.
> If you want to write predictable code - you have to init your
> variables/arrays. And check for existence/null. If fixed at least a few
> dozen bugs in my system I took over in the last few months specifically
> because of undefined variables or indexes.
>
> Never once have I advocated not initializing variables or arrays. I'm just
saying that we shouldn't force such behavior. Many of us can figure out
when we need the extra boilerplate and when we don't. Don't force us to
have to deal with the additional burden in every single case because
someone else can't.


> It works for small stuff, but when you have a codebase with 100+k LOC and
> more, you have to go strict or it starts to cost a lot of money and
> personnel to keep things running along.
>
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>


-- 
Chase Peeler
chasepee...@gmail.com

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

[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 satisfactory solution.
>


Agreed; it's certainly neater than all the isset() checks, but it's
definitely a bit ugly.

To clarify my point, the reason why people write this:

$foo[$key1][$key2]++;

Is not because they're lazy, it's because *it expresses their intent*.

The ?key syntax was one suggestion for how to express the intent safely in
that particular scenario. Another way might be that the array is
initialised a different way; completely off the top of my head, something
like this:

$foo = new Dictionary>;

That could express the intent of "this variable is going to be used as an
accumulator with these dimensions".

The "if isset" lines, in my opinion, don't express any intent, and they
don't protect against any real errors; they're just noise to work around a
short-coming in the language.

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[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 operator for
> > > "initialise and retrieve", such as $foo[? 'bar']. Then we could
> simplify
> > > ugly code like this:
> > >
> > > if ( ! isset($foo[$key1]) {
> > >$foo[$key1] = [];
> > > }
> > > if ( ! isset($foo[$key1][$key2]) {
> > >$foo[$key1][$key2] = 0;
> > > }
> > > $foo[$key1][$key2]++;
> > >
> > >
> > > With something safe but succinct like this:
> > >
> > > $foo[? $key1][? $key2]++;
> > >
> >
> > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> >
> > Marco Pivetta
> >
> > http://twitter.com/Ocramius
> >
> > http://ocramius.github.com/
> >
>
> This message contains a healthy dose of sarcasm.
>
> Hi Marko and Rowan :)
>
> *Me reviewing the PR with that code*
> *Clicks "Changes required"
> [ Please rewrite this statement into easy readable format with an if ]
> * Clicks send *
>
> Think what you must, but 6 months when you come back to code like this you
> have to stop, look at it hard and figure out what the hell actually happens
> there.
> Breaks reading flow.
>
> 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. Even Vagrantfile has tons of
> results about what syntax for arrays to use and things breaking because you
> end up mixing stuff and you get at least 4 different answers to the same
> question and it looks like all are correct. Confusing as hell :)
>
> What I'm trying to say is some of us choose PHP for it's "there is one
> syntax - use it". If people want syntax sugar - there are other languages
> that fit that much better. Leave us, peasants, in our peasant non-syntax
> sugar world alone :D
>
> Exactly. One common theme I've been seeing is "We already force our
developers to initialize variables, so, whats the big deal if you have to?"
or "We already force a no-notice environment, so what's the big deal if you
have to?"

If you're already doing it, then why do you feel the need to force others
to? You've proven that it can be done in the current system.

I'm making my prediction now - if this RFC passes, the adoption rate for
PHP 8 is going to be HORRIBLE.


> But many of us would also like the language engine to tighten up some of
> its extremely relaxed parts that do not fit in modern development
> environments and the lowest bar of the code quality rise a bit. Otherwise,
> the gap between high-end development and newbies is going to be even bigger
> than it is now.
> I hire people, that's part of my job. One of the criteria is the approach
> to errors/warning/notices. Imagine how that goes.
>
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>


-- 
Chase Peeler
chasepee...@gmail.com

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

[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 (twice the exact same lengthy expression
> > `$foo[$key1][$key2]`), so it is not a satisfactory solution.
> >
> > And that's why PHP is so awesome. You don't have to do all these stupid
> tricks just to do something simple like increment a counter. But, it looks
> like we're going to throw that out of the window because some people think
> that since they like doing it like the way above, everyone should have to.
>
> > —Claude
> >
> >
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Easy, because experience shows that leads to bugs and lots of them.
Security issues even.
If you want to write predictable code - you have to init your
variables/arrays. And check for existence/null. If fixed at least a few
dozen bugs in my system I took over in the last few months specifically
because of undefined variables or indexes.

It works for small stuff, but when you have a codebase with 100+k LOC and
more, you have to go strict or it starts to cost a lot of money and
personnel to keep things running along.

-- 
Arvīds Godjuks

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

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

[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 simplify
> > ugly code like this:
> >
> > if ( ! isset($foo[$key1]) {
> >$foo[$key1] = [];
> > }
> > if ( ! isset($foo[$key1][$key2]) {
> >$foo[$key1][$key2] = 0;
> > }
> > $foo[$key1][$key2]++;
> >
> >
> > With something safe but succinct like this:
> >
> > $foo[? $key1][? $key2]++;
> >
>
> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

This message contains a healthy dose of sarcasm.

Hi Marko and Rowan :)

*Me reviewing the PR with that code*
*Clicks "Changes required"
[ Please rewrite this statement into easy readable format with an if ]
* Clicks send *

Think what you must, but 6 months when you come back to code like this you
have to stop, look at it hard and figure out what the hell actually happens
there.
Breaks reading flow.

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. Even Vagrantfile has tons of
results about what syntax for arrays to use and things breaking because you
end up mixing stuff and you get at least 4 different answers to the same
question and it looks like all are correct. Confusing as hell :)

What I'm trying to say is some of us choose PHP for it's "there is one
syntax - use it". If people want syntax sugar - there are other languages
that fit that much better. Leave us, peasants, in our peasant non-syntax
sugar world alone :D

But many of us would also like the language engine to tighten up some of
its extremely relaxed parts that do not fit in modern development
environments and the lowest bar of the code quality rise a bit. Otherwise,
the gap between high-end development and newbies is going to be even bigger
than it is now.
I hire people, that's part of my job. One of the criteria is the approach
to errors/warning/notices. Imagine how that goes.

-- 
Arvīds Godjuks

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

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

[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 is not a satisfactory solution.
>
> And that's why PHP is so awesome. You don't have to do all these stupid
tricks just to do something simple like increment a counter. But, it looks
like we're going to throw that out of the window because some people think
that since they like doing it like the way above, everyone should have to.

> —Claude
>
>

-- 
Chase Peeler
chasepee...@gmail.com

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

[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

[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 exist, and of course there is often a proposal
> to have a declare statement or something similar, to allow their “code
> style” to run without errors.
> >
> >
> > So, my proposal to the situation is to introduce a single declare that
> solves that problem, once and for all.
> >
> >
> >   declare(sloppy=1);
> >
> >
> > This would suppress any errors about undefined variables, array offsets,
> would reverse the “bare words" change when encountering an undefined
> constant, etc. Heck, for good measure this mode could even re-implement
> register_globals and magic_quotes, because why not?
> >

This still forces people to opt-in to something that has been supported for
20+ years, and there isn't even a consensus on it being "sloppy" to begin
with.

>

>
> >
> > If you want to write sloppy code, that is entirely your prerogative, but
> please just own it for what it is, and stop pretending that it’s some
> herculean task to either define variables/offsets first; or check if
> they’re defined; or use an appropriate method to access them that
> specifically allows for undefined variables/offsets (i.e. the ?? and ??=
> operators)
> >
> >
>
> Declare(sloppy=yeah) is not granular enough. To all: please, do understand
> that everything is not black or white; this remark is not directed
> specifically to that particular issue, this is an attitude I see regularly
> on that mailing list.
>
> There is no such thing as “one true strict coding standard” and “one
> legacy lax coding standard”. For instance:
>
> * As time passes, we learn by experience what features were plain blunders
> (magic_quotes?), what features should have been more strict for the sake of
> catching bugs without imposing too much burden on users, what features
> could have been more strict, although that would impose to write lot of
> boiler code, etc. This process does not belong exclusively to some past
> dark age of sloppy and unsecure coding practices.
>
> * The degree of wanted strictness vary depending on occasions. For example
> when I’m writing a throw-away script, some notices are okay to indicate
> possible problems, but I’m not going to write boilerplate code (or, worse,
> put a @ in front of everything) just for the sake of silencing them. (But I
> *certainly* do not want stupid things like mistyped constants converted to
> string literals.) On the other hand, when I’m writing a critical part of an
> application, I am careful to write down everything precisely, and having to
> write explicitly and once for all that, yes, this precise variable must
> have that default value, is a minimal part of the time passed to write,
> re-read and review the code.
>
> What??? You mean it's possible to write strict code even when the engine
doesn't force you to? But I got the feeling that wasn't possible and we
needed to force EVERYONE to code this way.


> —Claude
> --
> 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

[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]) {
>$foo[$key1] = [];
> }
> if ( ! isset($foo[$key1][$key2]) {
>$foo[$key1][$key2] = 0;
> }
> $foo[$key1][$key2]++;
>
>
> With something safe but succinct like this:
>
> $foo[? $key1][? $key2]++;
>

$foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

[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 opinions *on both
sides*, we can look at *making the language more pleasant to use*.


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]) {
   $foo[$key1] = [];
}
if ( ! isset($foo[$key1][$key2]) {
   $foo[$key1][$key2] = 0;
}
$foo[$key1][$key2]++;


With something safe but succinct like this:

$foo[? $key1][? $key2]++;

Unlike the error suppression @ operator, this is not saying "I know I'm
doing something wrong, do it anyway"; it's saying "I want to do this
specific thing, I just want to do it in fewer lines of code".

The more helpers like this we have, the more I'd be amenable to
*eventually* raising things to Error - although I still think that should
be done over a longer period of time than a single release cycle.


Regards,
-- 
Rowan Tommins
[IMSoP]

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

[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 classified as Notice or Warning.

Regards,
-- 
Rowan Tommins
[IMSoP]

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

[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, than I've saved thanks to
> PHP's forgiving nature*.
> Hence even in the shittiest of my scripts, I usually end up registering an
> error handler to throw an exception even for the smallest notice. At least,
> I always get an exception right in my face when something's unexpected, so
> I can fix it and move on, and avoid surprises later on.
>
> Sure, in a quick script, I do see some value in being able to write stuff
> like:
>
> @ $array['non_existing_key']++;
>
> It's still sloppy though: what you're really doing is muting a notice and
> incrementing null.
> Instead, I feel like there should be a stronger support from the language
> to specifically handle this kind of use cases, rather than using them as a
> justification for not *severely *hardening error reporting.
> 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?
>
> In other words, if that was only me, the whole notice/warning stuff would
> go, and PHP would only have exceptions.
> Undefined variables would throw, undefined array keys would throw, and use
> cases like the above would have stronger language support to avoid
> boilerplate code full of if(isset()).
>
> — Benjamin
>

Every single workplace I worked in past 5 years always had 0 tolerance
policy for all notices, warnings and E_STRICT.
Since I started PHP in 2005, I have always worked with a 0
warning/notice/strict tolerance policy, in every workplace I have ever
worked. All those were fixed as bugs, heck even management pointed out
those from logging aggregation and made bugs to be fixed.
At this point, if I see that the company does not do this, I skip it.
Usually, it is a sign of way more stuff being wrong, but this alone is
already enough to have reservations about the advertised position.

The world has moved on how software is developed since the early 2000's
when this was okay. These days, at least in my dev circle, it is not okay
to have notices/warnings in your code.

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

[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 the shittiest of my scripts, I usually end up registering an
error handler to throw an exception even for the smallest notice. At least,
I always get an exception right in my face when something's unexpected, so
I can fix it and move on, and avoid surprises later on.

Sure, in a quick script, I do see some value in being able to write stuff
like:

@ $array['non_existing_key']++;

It's still sloppy though: what you're really doing is muting a notice and
incrementing null.
Instead, I feel like there should be a stronger support from the language
to specifically handle this kind of use cases, rather than using them as a
justification for not *severely *hardening error reporting.
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?

In other words, if that was only me, the whole notice/warning stuff would
go, and PHP would only have exceptions.
Undefined variables would throw, undefined array keys would throw, and use
cases like the above would have stronger language support to avoid
boilerplate code full of if(isset()).

— Benjamin

On Thu, 12 Sep 2019 at 11:42, 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 exist, and of course there is often a proposal
> to have a declare statement or something similar, to allow their “code
> style” to run without errors.
> >
> >
> > So, my proposal to the situation is to introduce a single declare that
> solves that problem, once and for all.
> >
> >
> >   declare(sloppy=1);
> >
> >
> > This would suppress any errors about undefined variables, array offsets,
> would reverse the “bare words" change when encountering an undefined
> constant, etc. Heck, for good measure this mode could even re-implement
> register_globals and magic_quotes, because why not?
> >
> >
> >
> > If you want to write sloppy code, that is entirely your prerogative, but
> please just own it for what it is, and stop pretending that it’s some
> herculean task to either define variables/offsets first; or check if
> they’re defined; or use an appropriate method to access them that
> specifically allows for undefined variables/offsets (i.e. the ?? and ??=
> operators)
> >
> >
>
> Declare(sloppy=yeah) is not granular enough. To all: please, do understand
> that everything is not black or white; this remark is not directed
> specifically to that particular issue, this is an attitude I see regularly
> on that mailing list.
>
> There is no such thing as “one true strict coding standard” and “one
> legacy lax coding standard”. For instance:
>
> * As time passes, we learn by experience what features were plain blunders
> (magic_quotes?), what features should have been more strict for the sake of
> catching bugs without imposing too much burden on users, what features
> could have been more strict, although that would impose to write lot of
> boiler code, etc. This process does not belong exclusively to some past
> dark age of sloppy and unsecure coding practices.
>
> * The degree of wanted strictness vary depending on occasions. For example
> when I’m writing a throw-away script, some notices are okay to indicate
> possible problems, but I’m not going to write boilerplate code (or, worse,
> put a @ in front of everything) just for the sake of silencing them. (But I
> *certainly* do not want stupid things like mistyped constants converted to
> string literals.) On the other hand, when I’m writing a critical part of an
> application, I am careful to write down everything precisely, and having to
> write explicitly and once for all that, yes, this precise variable must
> have that default value, is a minimal part of the time passed to write,
> re-read and review the code.
>
> —Claude
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[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 
> statement or something similar, to allow their “code style” to run without 
> errors.
> 
> 
> So, my proposal to the situation is to introduce a single declare that solves 
> that problem, once and for all.
> 
> 
>   declare(sloppy=1);
> 
> 
> This would suppress any errors about undefined variables, array offsets, 
> would reverse the “bare words" change when encountering an undefined 
> constant, etc. Heck, for good measure this mode could even re-implement 
> register_globals and magic_quotes, because why not? 
> 
> 
> 
> If you want to write sloppy code, that is entirely your prerogative, but 
> please just own it for what it is, and stop pretending that it’s some 
> herculean task to either define variables/offsets first; or check if they’re 
> defined; or use an appropriate method to access them that specifically allows 
> for undefined variables/offsets (i.e. the ?? and ??= operators)
> 
> 

Declare(sloppy=yeah) is not granular enough. To all: please, do understand that 
everything is not black or white; this remark is not directed specifically to 
that particular issue, this is an attitude I see regularly on that mailing list.

There is no such thing as “one true strict coding standard” and “one legacy lax 
coding standard”. For instance:

* As time passes, we learn by experience what features were plain blunders 
(magic_quotes?), what features should have been more strict for the sake of 
catching bugs without imposing too much burden on users, what features could 
have been more strict, although that would impose to write lot of boiler code, 
etc. This process does not belong exclusively to some past dark age of sloppy 
and unsecure coding practices.

* The degree of wanted strictness vary depending on occasions. For example when 
I’m writing a throw-away script, some notices are okay to indicate possible 
problems, but I’m not going to write boilerplate code (or, worse, put a @ in 
front of everything) just for the sake of silencing them. (But I *certainly* do 
not want stupid things like mistyped constants converted to string literals.) 
On the other hand, when I’m writing a critical part of an application, I am 
careful to write down everything precisely, and having to write explicitly and 
once for all that, yes, this precise variable must have that default value, is 
a minimal part of the time passed to write, re-read and review the code.

—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 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
> >>
> >
> > Heads up: This RFC may go to vote tomorrow.
> >
> > Nikita
>
>
> I have objections to those two reclassifications:
>
> * Undefined offset: %d — Notice → Warning
> * Undefined index: %d — Notice → Warning
>
>
> From experience, having to dutifully initialise each and every key in an
> array is burdensome. I understand the rationale of enforcing that in some
> coding standard; but whether those particular missing index should be
> considered as unexpected (therefore deserving a Warning) is mostly a
> question of coding style.
>
> This is in principle a similar issue as using uninitialised variables,
> which, as noted in this thread, is a perfectly accepted coding pattern in
> some languages (the issue being distinct from *undeclared* variables). I
> say “in principle”, because a perfectly reasonable coding style may choose
> to enforce initialisation of variables, but not of array keys.
>
> PHP has the advantage of supporting various coding styles. We should give
> the opportunity to the users to say declaratively (and precisely) what, in
> their coding style, is considered as acceptable, e.g.
>
> declare(
> uninitialized_variables: error
> uninitilalized_index: none
> );
>
> of course, possibly at a package-level declare. That would, for example,
> enable people to place legacy code in lax mode and chose a stricter mode
> for new code, even letting the precise notion of strictness vary with
> fashion without having to review working code written two years ago.
>
> That said, as long as those issues are handled as errors (as in:
> set_error_handler()) rather than exceptions, one may write a proper error
> handler that does the distinction (I do that). However, an error handler
> has the disadvantage of being global, making difficult the integration of
> code written with differing coding standards.
>
> —Claude
>

Hi Claude,

I have split off the question of undefined array keys into a separate
section, which will be voted separately.

I generally agree that ignoring undefined array key notices can be a
legitimate coding style choice (while I would very much disagree that the
same is true for undefined variables) -- though ultimately I think it is
best to handle this with a custom error handler (which can check whether
the error originated from your own codebase), rather than through a blanket
suppression of notices. In line with that thinking I don't think it matters
overly much whether it's a notice or warning for the purposes of
suppression. But I also don't feel particularly strongly about having this
case as a warning either, especially with the error_reporting=E_ALL default
in PHP 8.

Nikita

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

[Benjamin Morel]

>
> declare(sloppy=1);


I like this idea. Strict by default, sloppy by (code-level) config.

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

[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 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
>>> 
>> 
>> Heads up: This RFC may go to vote tomorrow.
>> 
>> Nikita
> 
> 
> I have objections to those two reclassifications:
> 
> * Undefined offset: %d — Notice → Warning
> * Undefined index: %d — Notice → Warning
> 
> 
> From experience, having to dutifully initialise each and every key in an 
> array is burdensome. I understand the rationale of enforcing that in some 
> coding standard; but whether those particular missing index should be 
> considered as unexpected (therefore deserving a Warning) is mostly a question 
> of coding style.
> 
> This is in principle a similar issue as using uninitialised variables, which, 
> as noted in this thread, is a perfectly accepted coding pattern in some 
> languages (the issue being distinct from *undeclared* variables). I say “in 
> principle”, because a perfectly reasonable coding style may choose to enforce 
> initialisation of variables, but not of array keys.
> 
> PHP has the advantage of supporting various coding styles. We should give the 
> opportunity to the users to say declaratively (and precisely) what, in their 
> coding style, is considered as acceptable, e.g.
> 
> declare(
>uninitialized_variables: error
>uninitilalized_index: none
> );
> 
> of course, possibly at a package-level declare. That would, for example, 
> enable people to place legacy code in lax mode and chose a stricter mode for 
> new code, even letting the precise notion of strictness vary with fashion 
> without having to review working code written two years ago.
> 
> That said, as long as those issues are handled as errors (as in: 
> set_error_handler()) rather than exceptions, one may write a proper error 
> handler that does the distinction (I do that). However, an error handler has 
> the disadvantage of being global, making difficult the integration of code 
> written with differing coding standards.
> 
> —Claude
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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 
statement or something similar, to allow their “code style” to run without 
errors.


So, my proposal to the situation is to introduce a single declare that solves 
that problem, once and for all.


declare(sloppy=1);


This would suppress any errors about undefined variables, array offsets, would 
reverse the “bare words" change when encountering an undefined constant, etc. 
Heck, for good measure this mode could even re-implement register_globals and 
magic_quotes, because why not? 



If you want to write sloppy code, that is entirely your prerogative, but please 
just own it for what it is, and stop pretending that it’s some herculean task 
to either define variables/offsets first; or check if they’re defined; or use 
an appropriate method to access them that specifically allows for undefined 
variables/offsets (i.e. the ?? and ??= operators)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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
>> 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
>> 
> 
> Heads up: This RFC may go to vote tomorrow.
> 
> Nikita


I have objections to those two reclassifications:

* Undefined offset: %d — Notice → Warning
* Undefined index: %d — Notice → Warning


From experience, having to dutifully initialise each and every key in an array 
is burdensome. I understand the rationale of enforcing that in some coding 
standard; but whether those particular missing index should be considered as 
unexpected (therefore deserving a Warning) is mostly a question of coding style.

This is in principle a similar issue as using uninitialised variables, which, 
as noted in this thread, is a perfectly accepted coding pattern in some 
languages (the issue being distinct from *undeclared* variables). I say “in 
principle”, because a perfectly reasonable coding style may choose to enforce 
initialisation of variables, but not of array keys.

PHP has the advantage of supporting various coding styles. We should give the 
opportunity to the users to say declaratively (and precisely) what, in their 
coding style, is considered as acceptable, e.g.

declare(
uninitialized_variables: error
uninitilalized_index: none
);

of course, possibly at a package-level declare. That would, for example, enable 
people to place legacy code in lax mode and chose a stricter mode for new code, 
even letting the precise notion of strictness vary with fashion without having 
to review working code written two years ago.

That said, as long as those issues are handled as errors (as in: 
set_error_handler()) rather than exceptions, one may write a proper error 
handler that does the distinction (I do that). However, an error handler has 
the disadvantage of being global, making difficult the integration of code 
written with differing coding standards.

—Claude

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 defined behavior, that is not going to break -
> > unless it is broken intentionally in a zeal for adding more strictness
> > for the sake of strictness. So, another thing to learn. I love learning
> > new things, and love helping others do so!
> >
> > It is well defined. It's also, in my PERSONAL opinion, gross AF.  That
> doesn't make me right or better or anything other than opinionated.
>
> Other opinions:
> * I'd quite like PHP to be a little less gross in places like this.
> * I think Nikita's hitlist here is a step in the right direction,
> however...
> * I DON'T think the cost to BC is justified in all cases. For example, an
> exception for read of undefined vars is traumatic BC.
> * I think declare(strict_types=1); already solved a very similar problem
> and could easily be applied to future issue like this.
>
> So how about we suck it up, put on our big girl panties, and just embrace
> declares (including namespace scoped declares and/or a modern version of
> .htaccess)
>
> -Sara
>

Hi Sara,

I do agree with most of it, especially about the big girl panties part, but
I do disagree with the declares part.
There should be one general use declare I think - declare(strict=1) - and
it should be the mode where PHP is going as a language into the future
and contain the strict types, stricter operators, the full suite of error
level rework (include everything Nikita has added in this RFC and probably
work on next iteration later),
have other stuff cleaned up too?

Here's the rationale:

Projects these days tend to be sizeable and growing all the time - they
require strictness to be maintainable by multiple people. We have seen a
rise of more strict and less feature-rich languages that are becoming a day
to day instruments for many things (Go anyone?) and the average skill of
the workforce has gone down somewhat a lot these past 10-15 years. So
tightening the screws is somewhat a necessity these days and leaving PHP
with its idiosyncrasies as it is right now in the weak mode is not a good
idea for the future. People have changed, development has changed, tools
have changed, how we write PHP code has changed DRAMATICALLY and PHP
community has been keeping up with past 5 years of PHP development faster
than PHP is evolving itself. I mean take NodeJS and JavaScript - their dev
cycles are running at breakneck speeds and you basically have to re-learn
things on a yearly basis to stay up to date. But it is a mess because the
ecosystem is young.
In PHP our ecosystem is mature, we have very good libraries and frameworks
that have clear release cycles and have reasonable upgrade paths and do
keep up with PHP itself - the adoption rates are probably at their highest
right now.
I say it's time to capitalize on this momentum and settle into a rhythm of
improving the language and its ecosystem by streamlining and building for
the next 20 years of it's lifecycle. With JIT coming up, a lot of things
will start to become possible and there are going to be a lot of things
that you want to make more explicit in the code to make sure JIT can take
advantage of and optimise.

So, back to the strict mode idea: why not introduce that mode in PHP 8
(fold strict_types into it and have a depreciation notice for strict_types
so people switch to declare(strict_mode=1) ), continue developing stuff for
that strict mode during the life of 8 versions and state everywhere that
this is preferred and future proof mode, in PHP 9 starts deprecating things
in non-strict mode pushing people to fix things like undefined variables,
index access notices, have more strict operators. An in PHP 10 basically
sunset the bad parts of the non-strict mode getting it closer up to the
stricter version in terms of the WTF parts of the language, but still leave
the fully dynamic and strict modes. Provided, ofc, that it is feasible,
though I would completely sunset non-strict mode at that point and leave
only one mode.

This essentially gives about a 10-year timeline of messaging, depreciation
and warnings to everyone. And at that point, if someone still did not do
anything to fix up things - well, I'm sorry, but it's your problem then to
figure out. I have done a few major 5 to 7 upgrades, one of them was an
especially bad case of PHP 5.1 to 7.1 cause it relied on PHP 4 behaviours
that were deprecated with PHP 5.0 and 5.1 and fatal error in 7 - it is not
as bad as many people think.

>

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

[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 broken intentionally in a zeal for adding more strictness
> for the sake of strictness. So, another thing to learn. I love learning
> new things, and love helping others do so!
>
> It is well defined. It's also, in my PERSONAL opinion, gross AF.  That
doesn't make me right or better or anything other than opinionated.

Other opinions:
* I'd quite like PHP to be a little less gross in places like this.
* I think Nikita's hitlist here is a step in the right direction, however...
* I DON'T think the cost to BC is justified in all cases. For example, an
exception for read of undefined vars is traumatic BC.
* I think declare(strict_types=1); already solved a very similar problem
and could easily be applied to future issue like this.

So how about we suck it up, put on our big girl panties, and just embrace
declares (including namespace scoped declares and/or a modern version of
.htaccess)

-Sara

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

[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 party code.

2. Undeclared values, or values of unexpected type, in variables
coming from elsewhere:
- variables used in file scope, e.g. in template files, which are
declared in a different file.
- any global variables.
- values in nested arrays, which might have been set in some other
place before they get passed to the current function.

Typically these cases are hard to fix and troubleshoot.
Especially, even if you think you fixed it, there can be some dynamic
conditions that are really hard to test.
E.g. if the username begins with a capital letter, the variable will
be undefined, or a specific array value will be an object instead of a
string..

Ideally such systems should be avoided, or they will need a lot of
try/catch to deal with such problems in the future.
But a lot of legacy code was not written with sufficient sanity
checks, and accepts the occasional or regular notice.

Perhaps is about time for this level of breakage in PHP8. I just want
us to be aware of it.

On Sat, 31 Aug 2019 at 05:23, Thomas Bley  wrote:
>
> That's a good point, maybe a compromise is this:
>
>  
> That way new users can always use  quickly patch the code with 
> Regards
> Thomas
>
> > 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 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.

yes..

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

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

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

Nikita,

Thank you for your effort in putting together this RFC and explaining
the rationale for each change. From my perspective, converting more
error conditions from a notice/warning to an exception as proposed
will be a welcome step forward for the language.

I've frequently used PHP to write one-time scripts for migrating data
between services, or scripting changes to thousands of items via an
API. The lack of exceptions for things like undefined variables and
using a scalar value as an array has bitten me on multiple occasions.

There have even been times when simple mistakes like a typo in a
variable name have led to data loss, since instead of causing the
script to halt it just output a notice and continued running with
bad data.

In my experience, PHP's historical lax treatment of errors, far from
making it faster and easier to write scripts, *actually makes it take
longer* since I have to add extra assertions and boilerplate custom
error handling code in order to ensure that scripts don't keep
running in a broken state when one of these errors occurs.

So in summary, I think the proposed RFC is a solid step forward which
will help prevent expensive mistakes and make it simpler to write
robust code.

With appreciation,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 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 broken intentionally in a zeal for adding more strictness
for the sake of strictness. So, another thing to learn. I love learning
new things, and love helping others do so!

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

[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
> the PHP equivalent of undefined behavior in C. And I don't think anyone
> would get mad if a new GCC version broke the way they were abusing UB.

That's where you are mixing things up: It is well-defined behaviour, even if 
you personally don't like it.

A better analogy is static variables in C. It is common (and not considered 
bad) practice to not explicitly set a variable to 0 as that is the default 
value.

Example: 
https://github.com/git/git/blob/6d5b26420848ec3bc7eae46a7ffa54f20276249d/delta-islands.c#L26

- Chris


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 PHP work would
> *love* some more strictness and I don't think keeping your old code
> running on a brand new version of the language is a good enough reason
> to keep this feature out of 8.0.


Strictness is undoubtedly a good thing — as a tool, not as a dogma. But BC 
break is not necessary for more strictness. As of today, you can write a custom 
error-handler that converts all non-handled warnings into program crashes 
(after having sent a fiery bug report to the developer).

—Claude

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

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


Today, PHP is a fully-fledged language *and* a templating system.

—Claude

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

[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 today if it weren't for "end of life".  I interpret the above paragraph as 
a request to split between p++ and php classic.  I'd be fine with that and use 
php classic, but I believe the idea of splitting failed by a very wide margin.

- Todd

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

[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 a new GCC version broke the way they were abusing UB.

To me and to every developer I've ever known, the only difference
between a notice and a warning is the severity of the error. But they're
both considered errors - mistakes you made in your code that you need to
fix. I'm fairly certain this is how most developers treat them in the
real world.

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 PHP work would
*love* some more strictness and I don't think keeping your old code
running on a brand new version of the language is a good enough reason
to keep this feature out of 8.0. What's the point of even having major
releases if every potential BC break gets shot down by the same 3 people
on this mailing list?

As for the check engine light analogy, I guess instead of saying "this
is fine", you just smash your entire dashboard with a hammer to make the
problem go away. Because that's what using @ or error_reporting does.

I hope this RFC passes, but I don't see any point in discussing it
further here, so I'll go back to lurking now.

On 29.08.2019 16:22, Zeev Suraski wrote:
>
>
> On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals
> mailto: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 notice consistently and every time it goes down this particular
> code path". Rather, I've always interpreted this as "under
> certain, rare, unforeseen circumstances, your code could generate
> a notice here, probably because of something that is outside of
> your control".
>
> That's how I've always treated them at least.
>
>
> And that's entirely within your right to do so - but what the manual
> says is accurate.  Calling me delusional in my interpretation of it is
> somewhat awkward (to put it mildly), I have a pretty good idea of why
> we added the different error levels - I wrote much of it myself.
>
> The whole point of having notices as something that's separate from
> warnings is that they have different semantics, and that semantics is
> captured very accurately in the manual.  They are used to mark issues
> which may be problems, but may also be perfectly fine (unlike
> warnings, which generally speaking mean that something bad happened,
> but not bad enough to halt execution).  Notices were meant to help you
> implement a more strict style of coding, and they may help you catch
> certain types of bugs, but you can have perfectly working, bug-free
> code that generates notices.
>
> Regardless of the exact semantics, don't you think a program that
> generates a constant stream of notices is a bit strange? That
> sounds like something everyone would naturally want to avoid. You
> don't drive your car with the check engine light permanently on
> and say "this is fine", right?
>
>
> Except you can purposely turn off this 'check engine' light, never to
> see it again if you choose to.  And that it's really not at all
> similar to 'check engine', but a lot closer to 'check cleaning fluid',
> or even 'clean windshield' (if cars had a dashboard light for that). 
> Even that is not a good analogy - as folks often actually purposely
> write code that generates notices (which would be purposely hidden,
> either by error_reporting setting or using @) that is 100% bug-free
> and working as intended.  So no, there's nothing strange about it if
> you buy into that approach.  If you don't (and I know you don't) -
> that's absolutely fine - it's up to you.
>
> Zeev
>

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

[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:
> 
>> 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
>>> "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 interpreted this as "under certain, rare, unforeseen
>>> circumstances, your code could generate a notice here, probably because
>> of
>>> something that is outside of your control".
>>> 
>>> That's how I've always treated them at least.
>>> 
>> 
>> And that's entirely within your right to do so - but what the manual says
>> is accurate.  Calling me delusional in my interpretation of it is somewhat
>> awkward (to put it mildly), I have a pretty good idea of why we added the
>> different error levels - I wrote much of it myself.
>> 
>> The whole point of having notices as something that's separate from
>> warnings is that they have different semantics, and that semantics is
>> captured very accurately in the manual.  They are used to mark issues which
>> may be problems, but may also be perfectly fine (unlike warnings, which
>> generally speaking mean that something bad happened, but not bad enough to
>> halt execution).  Notices were meant to help you implement a more strict
>> style of coding, and they may help you catch certain types of bugs, but you
>> can have perfectly working, bug-free code that generates notices.
>> 
>> Regardless of the exact semantics, don't you think a program that generates
>>> a constant stream of notices is a bit strange? That sounds like something
>>> everyone would naturally want to avoid. You don't drive your car with the
>>> check engine light permanently on and say "this is fine", right?
>> 
>> 
>> Except you can purposely turn off this 'check engine' light, never to see
>> it again if you choose to.  And that it's really not at all similar to
>> 'check engine', but a lot closer to 'check cleaning fluid', or even 'clean
>> windshield' (if cars had a dashboard light for that).  Even that is not a
>> good analogy - as folks often actually purposely write code that generates
>> notices (which would be purposely hidden, either by error_reporting setting
>> or using @) that is 100% bug-free and working as intended.  So no, there's
>> nothing strange about it if you buy into that approach.  If you don't (and
>> I know you don't) - that's absolutely fine - it's up to you.
>> 
>> Zeev
>> 
> I just wanted to bring up a few other points. First, as I think Stanislav
> has done a good job of pointing out, the flexibility of PHP is one of its
> greatest features. The nice thing about a flexible and forgiving language
> is that you can always put additional things in place on top of it to make
> it more strict and rigid if you want. Once you force a language to be
> strict and rigid, however, it's much harder, if not impossible, to add back
> in flexibility.
> 
> A lot of my emails on this thread have been focused on the burden to
> developers caused by the BC break. While I still think that is an important
> consideration, it distracted me from my initial view which was we shouldn't
> do this because it's just a bad idea. I understand all of the arguments for
> enforcing variable initialization. I agree with most of them as well.
> However, I think there are a myriad of ways that individuals and teams can
> do that enforcement without forcing it on every single developer whether
> they want it or not.
> 
> A lot of comparisons have been made to other languages. I do a lot of work
> with javascript and I have a good amount of experience with c# as well.
> I've used many other languages at times (c, c++, java, perl, ruby, etc.) as
> well. In c#, you don't have to initialize your variables - you have to
> declare them. Some types, like ints, are automatically initialized to 0
> unless explicitly initialized to something else. PHP doesn't require you to
> declare variables. So, while c# might require "int i; i++;" you can achieve
> the same thing in PHP with "$i++;" - neither one requires an explicit
> initialization.
> 
> A few people have referred to the fact that I have instances of undeclared
> variables as technical debt. As I said earlier, I've engaged in these
> discussions because I don't think just calling something technical debt
> should be justification for a change. The fact that a large number of
> developers might have technical debt in a certain area should be considered
> when weighing the pros and cons of a 

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

[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
> > "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 interpreted this as "under certain, rare, unforeseen
> > circumstances, your code could generate a notice here, probably because
> of
> > something that is outside of your control".
> >
> > That's how I've always treated them at least.
> >
>
> And that's entirely within your right to do so - but what the manual says
> is accurate.  Calling me delusional in my interpretation of it is somewhat
> awkward (to put it mildly), I have a pretty good idea of why we added the
> different error levels - I wrote much of it myself.
>
> The whole point of having notices as something that's separate from
> warnings is that they have different semantics, and that semantics is
> captured very accurately in the manual.  They are used to mark issues which
> may be problems, but may also be perfectly fine (unlike warnings, which
> generally speaking mean that something bad happened, but not bad enough to
> halt execution).  Notices were meant to help you implement a more strict
> style of coding, and they may help you catch certain types of bugs, but you
> can have perfectly working, bug-free code that generates notices.
>
> Regardless of the exact semantics, don't you think a program that generates
> > a constant stream of notices is a bit strange? That sounds like something
> > everyone would naturally want to avoid. You don't drive your car with the
> > check engine light permanently on and say "this is fine", right?
>
>
> Except you can purposely turn off this 'check engine' light, never to see
> it again if you choose to.  And that it's really not at all similar to
> 'check engine', but a lot closer to 'check cleaning fluid', or even 'clean
> windshield' (if cars had a dashboard light for that).  Even that is not a
> good analogy - as folks often actually purposely write code that generates
> notices (which would be purposely hidden, either by error_reporting setting
> or using @) that is 100% bug-free and working as intended.  So no, there's
> nothing strange about it if you buy into that approach.  If you don't (and
> I know you don't) - that's absolutely fine - it's up to you.
>
> Zeev
>
I just wanted to bring up a few other points. First, as I think Stanislav
has done a good job of pointing out, the flexibility of PHP is one of its
greatest features. The nice thing about a flexible and forgiving language
is that you can always put additional things in place on top of it to make
it more strict and rigid if you want. Once you force a language to be
strict and rigid, however, it's much harder, if not impossible, to add back
in flexibility.

A lot of my emails on this thread have been focused on the burden to
developers caused by the BC break. While I still think that is an important
consideration, it distracted me from my initial view which was we shouldn't
do this because it's just a bad idea. I understand all of the arguments for
enforcing variable initialization. I agree with most of them as well.
However, I think there are a myriad of ways that individuals and teams can
do that enforcement without forcing it on every single developer whether
they want it or not.

A lot of comparisons have been made to other languages. I do a lot of work
with javascript and I have a good amount of experience with c# as well.
I've used many other languages at times (c, c++, java, perl, ruby, etc.) as
well. In c#, you don't have to initialize your variables - you have to
declare them. Some types, like ints, are automatically initialized to 0
unless explicitly initialized to something else. PHP doesn't require you to
declare variables. So, while c# might require "int i; i++;" you can achieve
the same thing in PHP with "$i++;" - neither one requires an explicit
initialization.

A few people have referred to the fact that I have instances of undeclared
variables as technical debt. As I said earlier, I've engaged in these
discussions because I don't think just calling something technical debt
should be justification for a change. The fact that a large number of
developers might have technical debt in a certain area should be considered
when weighing the pros and cons of a breaking change. That being said, I do
NOT consider such code to be technical debt or bad code that needs to be
fixed. The only way it becomes either of those if with the implementation
of this RFC. It's a bit disingenuous to tell developers they have to make
large changes, and when they push back, tell them it's their fault for
accruing so much technical debt - when it's the RFC itself that actually
causes the 

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

[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 notice
> consistently and every time it goes down this particular code path".
> Rather, I've always interpreted this as "under certain, rare, unforeseen
> circumstances, your code could generate a notice here, probably because of
> something that is outside of your control".
>
> That's how I've always treated them at least.
>

And that's entirely within your right to do so - but what the manual says
is accurate.  Calling me delusional in my interpretation of it is somewhat
awkward (to put it mildly), I have a pretty good idea of why we added the
different error levels - I wrote much of it myself.

The whole point of having notices as something that's separate from
warnings is that they have different semantics, and that semantics is
captured very accurately in the manual.  They are used to mark issues which
may be problems, but may also be perfectly fine (unlike warnings, which
generally speaking mean that something bad happened, but not bad enough to
halt execution).  Notices were meant to help you implement a more strict
style of coding, and they may help you catch certain types of bugs, but you
can have perfectly working, bug-free code that generates notices.

Regardless of the exact semantics, don't you think a program that generates
> a constant stream of notices is a bit strange? That sounds like something
> everyone would naturally want to avoid. You don't drive your car with the
> check engine light permanently on and say "this is fine", right?


Except you can purposely turn off this 'check engine' light, never to see
it again if you choose to.  And that it's really not at all similar to
'check engine', but a lot closer to 'check cleaning fluid', or even 'clean
windshield' (if cars had a dashboard light for that).  Even that is not a
good analogy - as folks often actually purposely write code that generates
notices (which would be purposely hidden, either by error_reporting setting
or using @) that is 100% bug-free and working as intended.  So no, there's
nothing strange about it if you buy into that approach.  If you don't (and
I know you don't) - that's absolutely fine - it's up to you.

Zeev

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

[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 interpreted this as "under 
certain, rare, unforeseen circumstances, your code could generate a notice 
here, probably because of something that is outside of your control".

That's how I've always treated them at least.

Regardless of the exact semantics, don't you think a program that generates a 
constant stream of notices is a bit strange? That sounds like something 
everyone would naturally want to avoid. You don't drive your car with the check 
engine light permanently on and say "this is fine", right?

On 29.08.19 14:43, Claude Pache wrote:


Le 29 août 2019 à 13:33, Aegir Leet via internals 
mailto:internals@lists.php.net>> 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 
(https://www.php.net/errorfunc.constants):

E_NOTICE  — Run-time notices. Indicate that the script encountered something 
that could indicate an error, but could also happen in the normal course of 
running a script.

One can discuss whether unitialised variables should trigger a notice or a 
warning. But let us respect the semantics of the language features.

—Claude

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

[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 
(https://www.php.net/errorfunc.constants 
):

E_NOTICE  — Run-time notices. Indicate that the script encountered something 
that could indicate an error, but could also happen in the normal course of 
running a script.

One can discuss whether unitialised variables should trigger a notice or a 
warning. But let us respect the semantics of the language features.

—Claude

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

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

Is there any technical reason PHP can't go the transpiler route? Let
everyone experiment with their own preferred changes, and pull the best
ideas, once proven, into core PHP?

Peter

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

[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 you that might have less context.
> Also, code will evolve in time and bugs will eventually apear. In my
> opinion and maybe you can agree, some of these bugs could be avoided if
> variable definition before reading would be enforced.

... and that's why Zeev suggests a strict mode for people who want it that way.

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

> For most of the developers and businesses using PHP, that is a trade they
> want to enforce but can't or does not know how to do it.

That "most developers" is highly subjective depending on who you ask.
And yes, you can easily turn undefined variables into exceptions right now 
(even globally), just use

set_error_handler(function($errno, $errstr) {
if (preg_match('/^Undefined variable/', $errstr))
throw new Exception($errstr);
return false;
}, E_NOTICE);

> I am for a default with more things enforced and maybe only allowed them
> based on declares, not the other way around.

Breaking code first and making migration harder instead of offering a clean 
migration path where developers opt-in to a new mode.

- Chris


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[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 in time and bugs will eventually apear. In my
opinion and maybe you can agree, some of these bugs could be avoided if
variable definition before reading would be enforced.
Yes, it costs us more time to do it and productivity might be decreased by
1-2%.

For most of the developers and businesses using PHP, that is a trade they
want to enforce but can't or does not know how to do it.

I am for a default with more things enforced and maybe only allowed them
based on declares, not the other way around.

Regards,
Alex


On Thu, Aug 29, 2019, 08:52 Zeev Suraski  wrote:

> 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] [RFC] Reclassifying engine warnings

[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* 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] [RFC] Reclassifying engine warnings

[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 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] [RFC] Reclassifying engine warnings

[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;
> > $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

[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, 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

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

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

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

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

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

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

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

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

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

[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 || {};
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

[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 Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Kalle Sommer Nielsen]

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