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

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

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

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

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

> > declare(sloppy=1); I like this idea. Strict by default, sloppy by (code-level) config.

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

On Thu, Sep 12, 2019 at 9:40 AM Claude Pache wrote: > > Le 10 sept. 2019 à 15:31, Nikita Popov a écrit : > > > > On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov > wrote: > > > >> Hi internals, > >> > >> I think it's time to take a look at our existing warnings & notices in > the > >> engine, and

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

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

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

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

[PHP-DEV] PHP 7.3.10RC1 is available for testing

PHP 7.3.10RC1 has just been released and can be downloaded from: Or use the git tag: php-7.3.10RC1 Windows binaries are available at: Please test it carefully, and report any bugs in the bug system. 7.3.10 should be expected in

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

чт, 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

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

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

[PHP-DEV] [VOTE] Reclassifying engine warnings

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

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

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 in

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

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 opinio

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

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

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

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

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

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

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 wh

[PHP-DEV] [RFC] Object Initializer

Hi internals, I'd like to open discussion about RFC: Object Initializer. This proposal reduces boilerplate of object instantiation and properties initialization in case of classes without required constructor arguments as a single expression with initializer block. https://wiki.php.net/rfc/objec

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

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

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

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

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

чт, 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 (tw

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

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 opera

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

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 satis

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

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

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

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

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

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

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

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 paro

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

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 e

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

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

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

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(

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

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 k

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

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

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

[PHP-DEV] Changing fundamental language behaviors

I was really really hoping that we will avert having to dive into this and instead go for the alternative solution that was proposed of changing default php.ini error levels. But since the RFC went on to a vote - we need to make something clear. The RFC process was never, ever meant to handle

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

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

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, 12 Sep 2019 at 15:44, Zeev Suraski wrote: > > The RFC process was never, ever meant to handle fundamental changes to the > language. The only appropriate response to this is "lolwat?". You keep making up rules...that don't exist. You can't expect people to suddenly stop using RFCs to cha

Re: [PHP-DEV] Changing fundamental language behaviors

Hi Zeev, On Thu, Sep 12, 2019 at 4:44 PM Zeev Suraski wrote: > I was really really hoping that we will avert having to dive into this and > instead go for the alternative solution that was proposed of changing > default php.ini error levels. But since the RFC went on to a vote - we > need > to

Re: [PHP-DEV] Changing fundamental language behaviors

чт, 12 сент. 2019 г. в 16:53, Dan Ackroyd : > On Thu, 12 Sep 2019 at 15:44, Zeev Suraski wrote: > > > > The RFC process was never, ever meant to handle fundamental changes to > the > > language. > > The only appropriate response to this is "lolwat?". > > You keep making up rules...that don't exis

Re: [PHP-DEV] Changing fundamental language behaviors

On 12/09/2019 16:44, Zeev Suraski wrote: Similarly - adding typed variables - is certainly a future option. Changing PHP to require typed variables (without opting in) - is well outside of the internals@ mandate. For areas like that - our options are either doing nothing, or providing opt-

Re: [PHP-DEV] [RFC] Object Initializer

On Thu, Sep 12, 2019 at 4:00 PM Michał Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi internals, > > I'd like to open discussion about RFC: Object Initializer. > > This proposal reduces boilerplate of object instantiation and properties > initialization in case of classes without required

Re: [PHP-DEV] Changing fundamental language behaviors

You first me on that reply Dan, I guess I should just say "the naysayers are back", I can see their footprint all around. The RFC is Request for Comment on any changes, is there an explicit or implicit mention about what kind of proposed changes can be made? Mr/Mrs Zeev are you for PHP or against

Re: [PHP-DEV] [RFC] Object Initializer

The RFC is a beautiful feature suggestion, but something is telling me as beautiful and straightforward the syntax is, what can the use case be? I really love Constructor or Object initialization to be implemented in PHP, but is there something I think you're missing in the RFC? Thanks for the RF

RE: [PHP-DEV] Changing fundamental language behaviors

> -Original Message- > From: Marco Pivetta > Sent: Thursday, September 12, 2019 5:59 PM > To: Zeev Suraski > Cc: PHP Internals List > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > If you want to have an authoritative say on what the RFC process is for or > not,

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 11:01 AM Jordi Boggiano wrote: > On 12/09/2019 16:44, Zeev Suraski wrote: > > Similarly - adding typed variables - is certainly a future option. > Changing > > PHP to require typed variables (without opting in) - is well outside of > the > > internals@ mandate. > > > > > >

RE: [PHP-DEV] Changing fundamental language behaviors

> -Original Message- > From: Olumide Samson > Sent: Thursday, September 12, 2019 6:03 PM > To: Dan Ackroyd > Cc: Zeev Suraski ; PHP internals > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > The RFC is Request for Comment on any changes, is there an explicit or > im

[PHP-DEV] VCS Account Request: marandall

Registration recommended by participants of 11 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: marandall

VCS Account Approved: marandall approved by kalle \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changing fundamental language behaviors

Without your contributions in the early 2000s, PHP likely would not enjoy the popularity it does today. But I don't think that gives you veto power over the entire process. You haven't made any significant contributions to the codebase in over a decade, and yet the language has still gained many m

Re: [PHP-DEV] Changing fundamental language behaviors

> While I realize my email is unpleasant for many to read, it's in the context of an RFC that attempts to do something that is strictly inappropriate and out of the question. Stating the fact, that the RFC process was never meant to allow this to be done, is a statement of fact. [...] > There wo

Re: [PHP-DEV] Changing fundamental language behaviors

Hey Zeev. I'm not that deep into @internals and might not get the subtle subtext. English is not my native tongue so I might phrase things in a way that doesn't transport the whole meaning of my thoughts. But your Mail really left me curious: On Thu, 12 Sep 2019 at 10:44, Zeev Suraski wrote: >

Re: [PHP-DEV] Changing fundamental language behaviors

I'd like to weigh in as a voice of reason here. > There are no processes to make fundamental non-opt-in language changes in PHP. This part might be reasonable. > There won't be such processes either. These behaviors are here to stay. We > can tweak them, we can augment them - we do not get to d

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski wrote: > I'd like to weigh in as a voice of reason here. > > > There are no processes to make fundamental non-opt-in language changes > in PHP. > > This part might be reasonable. > > > There won't be such processes either. These behaviors are her

Re: [PHP-DEV] Changing fundamental language behaviors

Apologies for my semantic imprecision. I hope the intent of my email remains clear. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises On Thu, Sep 12, 2019 at 12:56 PM Chase Peeler wrote: > > > > On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski

Re: [PHP-DEV] Changing fundamental language behaviors

> > that don't fundamentally change the language There's clearly a big disagreement about whether this is a fundamental change or not. Preventing something that the entire field of software engineering frowns upon (and that most PHP developers avoid like the plague) doesn't seem like a *fundamen

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

Hi Larry, Thank you for the comment. > It seems like what you're describing here is more user-customizable > autoboxing than anything to do with union types. Your first statement ("user-customizable autoboxing") is probably fair to say. OTOH, rather than say "anything to do with union type"

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown wrote: > that don't fundamentally change the language > > > There's clearly a big disagreement about whether this is a fundamental > change or not. > > Preventing something that the entire field of software engineering frowns > upon (and that most PHP

Re: [PHP-DEV] Changing fundamental language behaviors

> > What if Java suddenly said that all properties are suddenly private, and > can only be accessed through getter/setter methods? > If Java announced that the next major version was to make the change after 95% of userland developers favoured it and over 2/3rds of their internals team did, I'd th

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler wrote: > There are valid reasons for not always initializing variables or array > keys. It might be a bad > reason in your opinion, but others view it as perfectly acceptable. > I recently had to fix a bug where a variable was renamed, caused a merge

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler wrote: > On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown > wrote: > > > that don't fundamentally change the language > > > > > > There's clearly a big disagreement about whether this is a fundamental > > change or not. > > > > Preventing something that

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown wrote: > What if Java suddenly said that all properties are suddenly private, and >> can only be accessed through getter/setter methods? >> > > If Java announced that the next major version was to make the change after > 95% of userland developers fav

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 1:39 PM Olumide Samson wrote: > > > On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler > wrote: > >> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown >> wrote: >> >> > that don't fundamentally change the language >> > >> > >> > There's clearly a big disagreement about whether thi

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown wrote: > What if Java suddenly said that all properties are suddenly private, and >> can only be accessed through getter/setter methods? >> > > If Java announced that the next major version was to make the change after > 95% of userland developers fav

Re: [PHP-DEV] Changing fundamental language behaviors

> On 13 Sep 2019, at 00:41, Chase Peeler wrote: > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown > wrote: > >> What if Java suddenly said that all properties are suddenly private, and >>> can only be accessed through getter/setter methods? >>> >> >> If Java announced that the next major ve

Re: [PHP-DEV] Changing fundamental language behaviors

> On Sep 12, 2019, at 10:37 AM, Lynn wrote: > > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler wrote: > >> There are valid reasons for not always initializing variables or array >> keys. It might be a bad >> reason in your opinion, but others view it as perfectly acceptable. >> > > I recently h

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler wrote: > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown > wrote: > > > What if Java suddenly said that all properties are suddenly private, and > >> can only be accessed through getter/setter methods? > >> > > > > If Java announced that the next major

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay wrote: > > > On 13 Sep 2019, at 00:41, Chase Peeler wrote: > > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown > > wrote: > > > >> What if Java suddenly said that all properties are suddenly private, and > >>> can only be accessed through getter/se

Re: [PHP-DEV] Changing fundamental language behaviors

I think it would do this list more good than not, if we talk or assume about some people who will ever or never upgrade... Seriously? How do you know if they would never or ever upgrade, you can only and should probably speak for yourself... If they want more customers(translating to revenue), the

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 2:07 PM Olumide Samson wrote: > I think it would do this list more good than not, if we talk or assume > about some people who will ever or never upgrade... > Seriously? > How do you know if they would never or ever upgrade, you can only and > should probably speak for you

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel wrote: > > > Just a few weeks ago I was refactoring some particularly horrible code > developed by previously employed developers — a code based that has a 1400 > line function and many other functions 100s of lines long, and I added some > initializa

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 1:58 PM Olumide Samson wrote: > > > On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler > wrote: > >> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown >> wrote: >> >> > What if Java suddenly said that all properties are suddenly private, and >> >> can only be accessed through gett

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 7:10 PM Lynn wrote: > On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel wrote: > > > > > > > Just a few weeks ago I was refactoring some particularly horrible code > > developed by previously employed developers — a code based that has a > 1400 > > line function and many othe

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 2:10 PM Lynn wrote: > On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel wrote: > > > > > > > Just a few weeks ago I was refactoring some particularly horrible code > > developed by previously employed developers — a code based that has a > 1400 > > line function and many othe

Re: [PHP-DEV] Changing fundamental language behaviors

> On 13 Sep 2019, at 01:07, Chase Peeler wrote: > > > > On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay wrote: > > > On 13 Sep 2019, at 00:41, Chase Peeler wrote: > > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown > > wrote: > > > >> What if Java suddenly said that all properties are su

Re: [PHP-DEV] Changing fundamental language behaviors

I'm sure that some people wrote code like this, expecting it to always work in PHP: if ($some_condition) define("HELLO", 0); if (HELLO) { var_dump("got here"); } The equivalent, relying on buggy behaviour, PHP code looks like if ($some_condition) $hello = 1; if (!$hello) { var_dump("got here");

Re: [PHP-DEV] Changing fundamental language behaviors

Indeed, for the case of local variables that were undefined before, this can usually be fixed in a straightforward way by initializing to NULL. The goal here is to get rid of the error or notice while preserving the original behavior (even if it was buggy). This is IF this is your own custom code,

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl wrote: > > > > You may be wondering, in that case, what processes do we have to deal > with > > such changes then? The answer is simple. We don't. We don't have to > have > > them either - the fundamental language behaviors are here to stay. > > Bu

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, 12 Sep 2019 at 20:35, Zeev Suraski wrote: > > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl wrote: > > > > > > > > You may be wondering, in that case, what processes do we have to deal > > with > > > such changes then? The answer is simple. We don't. We don't have to > > have > > > the

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot wrote: > Just a dumb idea, since there clearly is a majority in favor of the > change with these warnings and strictness and all that now... Why not > making something like an LTS PHP 7.x where all the legacy code would > work OK as long as practically

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 2:51 PM Peter Kokot wrote: > On Thu, 12 Sep 2019 at 20:35, Zeev Suraski wrote: > > > > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl wrote: > > > > > > > > > > > > You may be wondering, in that case, what processes do we have to deal > > > with > > > > such changes then?

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 2:35 PM Zeev Suraski wrote: > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl wrote: > > > > > > > > You may be wondering, in that case, what processes do we have to deal > > with > > > such changes then? The answer is simple. We don't. We don't have to > > have > > > th

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 8:00 PM Michael Babker wrote: > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot wrote: > > > Just a dumb idea, since there clearly is a majority in favor of the > > change with these warnings and strictness and all that now... Why not > > making something like an LTS PHP 7.x

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson wrote: > On Thu, Sep 12, 2019 at 8:00 PM Michael Babker > wrote: > >> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot wrote: >> >> > Just a dumb idea, since there clearly is a majority in favor of the >> > change with these warnings and strictness and

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson wrote: > On Thu, Sep 12, 2019 at 8:00 PM Michael Babker > wrote: > > > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot > wrote: > > > > > Just a dumb idea, since there clearly is a majority in favor of the > > > change with these warnings and strictnes

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 8:11 PM Michael Babker wrote: > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson > wrote: > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker >> wrote: >> >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot >>> wrote: >>> >>> > Just a dumb idea, since there clearly is a major

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 8:15 PM Chase Peeler wrote: > > > On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson > wrote: > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker >> wrote: >> >> > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot >> wrote: >> > >> > > Just a dumb idea, since there clearly is a m

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 2:17 PM Olumide Samson wrote: > Most of these changes wouldn't have been problematic to you if the > language has prevented you from writing what we can now consider bad code, > so please allow the new PHP developer that newly start using PHP to not > follow that your path

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson wrote: > On Thu, Sep 12, 2019 at 8:11 PM Michael Babker > wrote: > > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson > > wrote: > > > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker < > michael.bab...@gmail.com> > >> wrote: > >> > >>> On Thu, Se

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 8:29 PM Chase Peeler wrote: > > > On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson > wrote: > >> On Thu, Sep 12, 2019 at 8:11 PM Michael Babker >> wrote: >> >> > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson >> > wrote: >> > >> >> On Thu, Sep 12, 2019 at 8:00 PM Michael

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

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 th

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, 12 Sep 2019 at 19:10, Lynn wrote: > Whenever one of these errors will occur, you can initialize either the > array key or variable with null and it will work again without changing > behavior. If anything, Wordpress shouldn't be an argument to not improve > PHP, though I think it's import

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

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

Re: [PHP-DEV] Changing fundamental language behaviors

Hi guys, > Many of us don't consider it bad code. I've also always initialized > variables when it was required (and many times when it wasn't) even though > I wasn't forced to do so. A lot of other people do as well. If it's so > important to you, start a program to teach people how you think the

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 4:59 PM Alexandru Pătrănescu wrote: > Hi guys, > > > Many of us don't consider it bad code. I've also always initialized > > variables when it was required (and many times when it wasn't) even > though > > I wasn't forced to do so. A lot of other people do as well. If it's

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer wrote: > > One can argue that WordPress, with it powering 34% of the web (source: > wordpress.org) represents more than 50% of PHP users, and therefore > aligning the language to how they use it would be sensible, as they are the > majority of users.

Re: [PHP-DEV] Changing fundamental language behaviors

On Sep 12, 2019, at 11:06 AM, Olumide Samson wrote: > I think they could switch to using null instead, or perhaps get something > else to differentiate what they have initialized or not, Perhaps, but switching the code requires finding the right people to do the work and then funding the change

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

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 on

Re: [PHP-DEV] Changing fundamental language behaviors

On Fri, Sep 13, 2019 at 12:00 AM Alexandru Pătrănescu wrote: > Also, I would also like to remind of this: > https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md > I think some parts might have been violated multiple time in this thread. As was already pointed out in a different

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

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 s

Re: [PHP-DEV] Changing fundamental language behaviors

> Whenever one of these errors will occur, you can initialize either the array > key or variable with null and it will work again without changing behavior. Whatever the case, changing warnings to errors would require fixing working code. And for many people, that would requiring investing lots

Re: [PHP-DEV] Changing fundamental language behaviors

> It's not a matter of won't upgrade, but that they can't upgrade. If Wordpress > decides to take their time supporting PHP 8, wordpress users won't have any > option but to wait on upgrading. To be clear, WordPress core upgrading to support PHP won't be a big issue. And WordPress core code ha

Re: [PHP-DEV] Changing fundamental language behaviors

On Fri, Sep 13, 2019 at 12:35 AM Lynn wrote: > On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer > wrote: > > > > > One can argue that WordPress, with it powering 34% of the web (source: > > wordpress.org) represents more than 50% of PHP users, and therefore > > aligning the language to how they use

  1   2   >