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

[Christoph M. Becker]

On 15.10.2019 at 10:27, Gert wrote:

> I may be a bit late to this party, but will the promotion to error
> exception of illegal offsets also happen for using resources as array
> keys? These currently produce a notice, and are then casted to an
> integer: https://3v4l.org/cQ8hf
> Or will the behaviour of that remain the same?

Only objects and arrays will throw; resources are promoted from E_NOTICE
to E_WARNING.

--
Christoph M. Becker

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

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

[Gert]

I may be a bit late to this party, but will the promotion to error
exception of illegal offsets also happen for using resources as array
keys? These currently produce a notice, and are then casted to an
integer: https://3v4l.org/cQ8hf
Or will the behaviour of that remain the same?

On Fri, 11 Oct 2019 at 18:16, Claude Pache  wrote:
>
>
>
> > Le 11 oct. 2019 à 11:12, Olumide Samson  a écrit :
> >
> > On Fri, Oct 11, 2019, 9:29 AM Benjamin Morel 
> > wrote:
> >
> >>>
> >>> As people have expressed interest in hearing about direct technical
> >>> benefits that these kinds of changes have ... let me give you an example
> >>> that came up yesterday.
> >>
> >>
> >>
> >> Too bad this example comes after the vote has been made, and failed.
> >> This would be a very strong argument in favour of using exceptions
> >> everywhere in the next major version: codebase cleanup, room for more
> >> optimization.
> >>
> >> Nikita, please fork PHP, we'll follow you ;-)
> >>
> >> — Benjamin
> >>
> >
> > I think I'm always available to contribute to a fork of a better PHP, coz I
> > love the syntax not the garbages included in the current one.
>
> If you’re seeking a fork of PHP that wilfully breaks BC for the sake of 
> cleanup and optimisation, you should seriously consider Hack. Although I 
> don’t know whether they’ve already removed support of the appalling implicit 
> initialisation of  variables to `null`, or of the dreadful backtick operator, 
> you’ll be delighted to learn that they’re on the process of removing 
> references, PHP arrays (in favour of Hack arrays and collections), and even 
> that little pesky ` ;-)
>
> https://hhvm.com/blog/2019/02/11/hhvm-4.0.0.html 
> 
>
> Enjoy. (But not with me: our company does not have the budget to migrate 30 
> Mo of code without counting external libraries.)
>
> —Claude
>
>

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

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

[Claude Pache]

> Le 11 oct. 2019 à 11:12, Olumide Samson  a écrit :
> 
> On Fri, Oct 11, 2019, 9:29 AM Benjamin Morel 
> wrote:
> 
>>> 
>>> As people have expressed interest in hearing about direct technical
>>> benefits that these kinds of changes have ... let me give you an example
>>> that came up yesterday.
>> 
>> 
>> 
>> Too bad this example comes after the vote has been made, and failed.
>> This would be a very strong argument in favour of using exceptions
>> everywhere in the next major version: codebase cleanup, room for more
>> optimization.
>> 
>> Nikita, please fork PHP, we'll follow you ;-)
>> 
>> — Benjamin
>> 
> 
> I think I'm always available to contribute to a fork of a better PHP, coz I
> love the syntax not the garbages included in the current one.

If you’re seeking a fork of PHP that wilfully breaks BC for the sake of cleanup 
and optimisation, you should seriously consider Hack. Although I don’t know 
whether they’ve already removed support of the appalling implicit 
initialisation of  variables to `null`, or of the dreadful backtick operator, 
you’ll be delighted to learn that they’re on the process of removing 
references, PHP arrays (in favour of Hack arrays and collections), and even 
that little pesky `https://hhvm.com/blog/2019/02/11/hhvm-4.0.0.html 


Enjoy. (But not with me: our company does not have the budget to migrate 30 Mo 
of code without counting external libraries.)

—Claude

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

[Chase Peeler]

On Thu, Sep 26, 2019 at 4:31 AM Christian Schneider 
wrote:

> Am 26.09.2019 um 09:41 schrieb Nikita Popov :
> > * Remainder: 54 yes, 3 no. Accepted with 95% majority.
>
> Just for the record:
> The one I'm most concerned about here is the foreach on undefined
> variables throwing an exception.
> While this was already promoted to a warning at an earlier stage it still
> allowed a program to finish with a well-defined result (looping over
> nothing does nothing).
> Now this code will stop with an Exception and possibly won't produce its
> output.
>
> I agree. At the very least, I'd propose that null (and ideally false) NOT
throw an exception. There are enough instances of methods that return one
of those values when there is no data (so, not an error situation) but an
array when there is.


> I noticed this before the vote but as the mailing list was already flooded
> with the 'undefined variables' discussion I feared that there was no place
> to bring this up without getting personally attacked like I was for the
> undefined variables stuff.
>
> Thanks for bringing this up. I think this should be noted in relation to
the other RFC currently out there. Those of us speaking out against this
RFC are the ones being held up as examples of why that RFC is needed, which
this statement actually shows that it was those in favor of the RFC that
were behaving in a way that intimidated others and made them feel reluctant
to contribute.


> Anyway, the vote is done, I said my piece and will shut up about it now,
> - Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

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

[Christian Schneider]

Am 26.09.2019 um 09:41 schrieb Nikita Popov :
> * Remainder: 54 yes, 3 no. Accepted with 95% majority.

Just for the record:
The one I'm most concerned about here is the foreach on undefined variables 
throwing an exception.
While this was already promoted to a warning at an earlier stage it still 
allowed a program to finish with a well-defined result (looping over nothing 
does nothing).
Now this code will stop with an Exception and possibly won't produce its output.

I noticed this before the vote but as the mailing list was already flooded with 
the 'undefined variables' discussion I feared that there was no place to bring 
this up without getting personally attacked like I was for the undefined 
variables stuff.

Anyway, the vote is done, I said my piece and will shut up about it now,
- Chris

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

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

[Björn Larsson]

Den 2019-09-18 kl. 21:44, skrev Claude Pache:


Le 18 sept. 2019 à 18:28, Nikita Popov  a écrit :

I just realized that I missed one notice here, because it is generated from
a different location: "Constant %s already defined" (The define/const will
be ignored and the previous value used.)

It would be great to have that as an exception for optimization reasons,
but as it's only a notice right now ... what do people think about
promoting it to a warning?

Nikita

Since attempting to define an already defined constant fails to perform the 
expected operation (i.e., defining the constant to *that* value), I think that 
a Warning is very reasonable.

—Claude


I also think that a warning would be appropriate here.
Have stumbled on it myself, not having notices on.

r//Björn L

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

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

[Claude Pache]

> Le 18 sept. 2019 à 18:28, Nikita Popov  a écrit :
> 
> I just realized that I missed one notice here, because it is generated from
> a different location: "Constant %s already defined" (The define/const will
> be ignored and the previous value used.)
> 
> It would be great to have that as an exception for optimization reasons,
> but as it's only a notice right now ... what do people think about
> promoting it to a warning?
> 
> Nikita

Since attempting to define an already defined constant fails to perform the 
expected operation (i.e., defining the constant to *that* value), I think that 
a Warning is very reasonable.

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

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

[Chase Peeler]

On Thu, Sep 12, 2019 at 10:13 AM Olumide Samson 
wrote:

>
>
> On Thu, Sep 12, 2019, 2:59 PM Chase Peeler  wrote:
>
>>
>>
>> On Thu, Sep 12, 2019 at 8:33 AM Olumide Samson 
>> wrote:
>>
>>> Thanks to those who can vote, all in all I hope for a better language
>>> where
>>> we can proudly post jobs(even intern) for on our company's website
>>> without
>>> been looked down on as inferior.
>>>
>>> If you're so embarrassed by the language, then why not use something
>> else, instead of trying to force such massive changes on the entire user
>> base?
>>
> Anything considered through vote is opinion based, not the way you could
> call "force" and I think you can also ask those who are not embarrassed by
> the current language situation to stick to whatever is their current
> version. Upgrading can't be for everyone.
> Only those who like major features/changes  of a new version upgrade.
>
I do like new features. There are tons of new features that can be added
without such a massive and unnecessary BC break.


>
>> Also, if you really think this is going to change how non-PHP developers
>> view PHP, you're sorely mistaken. The few I've talked to about this, in
>> order to gauge how the languages they work in handle BC breaks, were
>> appalled that such a major breakage would be forced on users, even though
>> they personally don't like the fact that PHP supports uninitialized
>> variables.
>>
> I'm sure you are the one mistaken here, cos you don't speak for non-PHP
> developers likewise I don't.
>
> You can in all utmost speak for yourself like I did In my last email.
>
>>
>> I'm not claiming to speak for everyone. I did provide some anecdotal
evidence though.


> Again, I implore everyone to stop trying and make everyone else like us.
>> Our language is awesome because of the fact that it is different and
>> flexible. That flexibility allows you to be strict if you want. If we just
>> want to turn PHP into another language that is like everything else out
>> there, then what's the point of even using PHP to begin with?
>>
>>
> I'm sure you are insulting the Project through those written words. If the
> project still want to be what it has always been, then there's no want or
> need for anything called @internals cos the language can actually still
> stick to PHP 3 and become what it has always been without any updates or
> changes.
>
> Not an insult at all. PHP has made a lot of awesome improvements, and
continues to make more. We can add things like union types, enums, etc.,
without losing the flexibility that makes the language great. This RFC
takes away something that, in the opinion of many, makes PHP better than
the other options out there.


> Like I said, since I can't vote I can only hope for the best.
>
> Since I can't vote, I can only hope for the best.
>>>
>>> <3
>>>
>>> On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:
>>>
>>> > Hi internals,
>>> >
>>> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
>>> >
>>> > There are 4 votes, all of them independent. The first 3 are for
>>> specific
>>> > cases that were controversial during the discussion, the last one is
>>> for
>>> > the remainder of the proposal.
>>> >
>>> > Voting closes 2019-09-26.
>>> >
>>> > Regards,
>>> > Nikita
>>> >
>>>
>>
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>

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

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

[Olumide Samson]

On Thu, Sep 12, 2019, 2:59 PM Chase Peeler  wrote:

>
>
> On Thu, Sep 12, 2019 at 8:33 AM Olumide Samson 
> wrote:
>
>> Thanks to those who can vote, all in all I hope for a better language
>> where
>> we can proudly post jobs(even intern) for on our company's website without
>> been looked down on as inferior.
>>
>> If you're so embarrassed by the language, then why not use something
> else, instead of trying to force such massive changes on the entire user
> base?
>
Anything considered through vote is opinion based, not the way you could
call "force" and I think you can also ask those who are not embarrassed by
the current language situation to stick to whatever is their current
version. Upgrading can't be for everyone.
Only those who like major features/changes  of a new version upgrade.

>
> Also, if you really think this is going to change how non-PHP developers
> view PHP, you're sorely mistaken. The few I've talked to about this, in
> order to gauge how the languages they work in handle BC breaks, were
> appalled that such a major breakage would be forced on users, even though
> they personally don't like the fact that PHP supports uninitialized
> variables.
>
I'm sure you are the one mistaken here, cos you don't speak for non-PHP
developers likewise I don't.

You can in all utmost speak for yourself like I did In my last email.

>
> Again, I implore everyone to stop trying and make everyone else like us.
> Our language is awesome because of the fact that it is different and
> flexible. That flexibility allows you to be strict if you want. If we just
> want to turn PHP into another language that is like everything else out
> there, then what's the point of even using PHP to begin with?
>
>
I'm sure you are insulting the Project through those written words. If the
project still want to be what it has always been, then there's no want or
need for anything called @internals cos the language can actually still
stick to PHP 3 and become what it has always been without any updates or
changes.

Like I said, since I can't vote I can only hope for the best.

Since I can't vote, I can only hope for the best.
>>
>> <3
>>
>> On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:
>>
>> > Hi internals,
>> >
>> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
>> >
>> > There are 4 votes, all of them independent. The first 3 are for specific
>> > cases that were controversial during the discussion, the last one is for
>> > the remainder of the proposal.
>> >
>> > Voting closes 2019-09-26.
>> >
>> > Regards,
>> > Nikita
>> >
>>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

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

[Chase Peeler]

On Thu, Sep 12, 2019 at 8:33 AM Olumide Samson  wrote:

> Thanks to those who can vote, all in all I hope for a better language where
> we can proudly post jobs(even intern) for on our company's website without
> been looked down on as inferior.
>
> If you're so embarrassed by the language, then why not use something else,
instead of trying to force such massive changes on the entire user base?

Also, if you really think this is going to change how non-PHP developers
view PHP, you're sorely mistaken. The few I've talked to about this, in
order to gauge how the languages they work in handle BC breaks, were
appalled that such a major breakage would be forced on users, even though
they personally don't like the fact that PHP supports uninitialized
variables.

Again, I implore everyone to stop trying and make everyone else like us.
Our language is awesome because of the fact that it is different and
flexible. That flexibility allows you to be strict if you want. If we just
want to turn PHP into another language that is like everything else out
there, then what's the point of even using PHP to begin with?


> Since I can't vote, I can only hope for the best.
>
> <3
>
> On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
> >
> > There are 4 votes, all of them independent. The first 3 are for specific
> > cases that were controversial during the discussion, the last one is for
> > the remainder of the proposal.
> >
> > Voting closes 2019-09-26.
> >
> > Regards,
> > Nikita
> >
>


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

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

[Olumide Samson]

Thanks to those who can vote, all in all I hope for a better language where
we can proudly post jobs(even intern) for on our company's website without
been looked down on as inferior.

Since I can't vote, I can only hope for the best.

<3

On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:

> Hi internals,
>
> I've opened the vote on //wiki.php.net/rfc/engine_warnings.
>
> There are 4 votes, all of them independent. The first 3 are for specific
> cases that were controversial during the discussion, the last one is for
> the remainder of the proposal.
>
> Voting closes 2019-09-26.
>
> Regards,
> Nikita
>