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

Hi Lynn, czw., 12 wrz 2019 o 17:01 Lynn napisał(a): > Heya, > > What's the added benefit of this compared to implementing a constructor? > > The part I like is that this can be used to replace stdClass/structured > arrays. Perhaps something like this would nice to have in PHP: > > ``` > $people

[PHP-DEV] Happy International programmers day!

Hi internals! Thank you for supporting and improving PHP! https://github.com/php/php-src/graphs/contributors Have a great day celebrating the 256th day of this year! You are great and you should know this. Thank you!

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019, 10:15 PM Chase Peeler wrote: > > > 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 >>

Re: [PHP-DEV] Changing fundamental language behaviors

Hi Zeev, I just reminded the rules so everyone remembers we have them for this mailing list. I actually was not referring to hints 1 and 2, even if I still believe they are good hints to follow in order to have the discussion more productive and respectful to everyone. I was actually referring

Re: [PHP-DEV] Changing fundamental language behaviors

> On 13 Sep 2019, at 2:50, Joe Watkins wrote: > > Zeev, > > > Without getting to the technicalities, simply put, no. > > I'm not sure what you intend to do to stop it. I sincerely hope reason will prevail and we won't have to find out (as I was hoping this part of the RFC won't be put up

Re: [PHP-DEV] Changing fundamental language behaviors

Zeev, > Without getting to the technicalities, simply put, no. I'm not sure what you intend to do to stop it. Once again, I remind you that you don't have the authority that your behaviour communicates you have, at all. I wasn't starting a conversation, I was communicating facts, and I'm

Re: [PHP-DEV] Changing fundamental language behaviors

On 13 Sep 2019, at 2:21, Joe Watkins mailto:krak...@gmail.com>> wrote: Zeev, I'm going to keep this really short and simple ... I'll do the same. You don't have the authority to make unilateral decisions for PHP,. Neither does anybody else on this list. Not even a plurality or a majority

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

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,

Re: [PHP-DEV] Changing fundamental language behaviors

Zeev, I'm going to keep this really short and simple ... You don't have the authority to make unilateral decisions for PHP,. Nothing you are saying is going to have any effect, the people who actually work on the language will merge whatever is voted in. Cheers On Fri, 13 Sep 2019, 00:17 Mike

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

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

Re: [PHP-DEV] Changing fundamental language behaviors

> How many of those are actually developers? Because the way I understand this > numbers, "powering the web", that doesn't mean 34% are also developers. It > wouldn't surprise me if a big portion of these applications could've also be > a system written in another language, deployed, plugins

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

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

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

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

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

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

Re: [PHP-DEV] 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

[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

[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

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 >

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

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

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

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

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

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 >

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

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

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

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

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

Re: [PHP-DEV] [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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >