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

Hi Mike, I am curious why your RFC uses "=" instead of "=>" for separating > properties from values? > > If we used "=>" it is potential — with lookahead parsing — that the > following could be unambiguous: > > { foo => 10 } > > The reason about choosing "=" was a simplification of instantiation

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

Hi Arnold, pt., 13 wrz 2019 o 10:51 Arnold Daniels napisał(a): > This can easily be done in a number of ways, like the suggested helper > function. The same can be said for many other features that were > implemented recently, like array unpacking. This feature is easy to > implement and will

Re: [PHP-DEV] Changing fundamental language behaviors

On Fri, Sep 13, 2019 at 11:59 AM Olumide Samson wrote: > "We know it is bad or can be devastating Actually, that's not at all what we're saying. I think that doing something like @$foo++ is absolutely fine. Many others on this (and related) threads think so too. I find all the 'improvements'

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

> IMO should stay specific for arrays only. Why? Is there an objective reason? Is there some aspect of the syntax that makes it appropriate for arrays but inappropriate for object initialization? These are honest question. My two cents: I would like to type less too, but I have always

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

pt., 13 wrz 2019 o 11:29 Mike Schinkel napisał(a): > IMO should stay specific for arrays only. > > > Why? Is there an objective reason? > > $obj->foo => 123; Simply, that's not the way you initialize object property values. When you use "=>" in array context you're pushing a new value to array

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

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

Re: [PHP-DEV] Changing fundamental language behaviors

Le 12/09/2019 à 20:51, Peter Kokot a écrit : > 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] [RFC] Object Initializer

On Fri, Sep 13, 2019 at 12:18 PM Rasmus Schultz wrote: > I'd like to address the examples - and why I think they don't demonstrate > that this feature is really useful in practice. > > There are several examples similar to this one: > > class Car > { > public int $yearOfProduction; > public

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

> On Sep 13, 2019, at 2:39 AM, Michał Brzuchalski > wrote: > $obj->foo => 123; > Simply, that's not the way you initialize object property values. So by the same logic this should be PHP's way to initialize array elements, right? $arr['foo'] => 123; But it is not. Obviously we both know that

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

> I don't like how it works for anonymous classes. It's more difficult to >> implement since the compiler doesn't know the meaning of the (first) >> bracket. It's doesn't make the code more readable, for the same reason. I >> think it's better to not support this syntax with anonymous classes. >>

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

On Fri, Sep 13, 2019 at 10:51 AM Arnold Daniels < arnold.adaniels...@gmail.com> wrote: > Comments: > > I don't like how it works for anonymous classes. It's more difficult to > implement since the compiler doesn't know the meaning of the (first) > bracket. It's doesn't make the code more

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

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

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

I'd like to address the examples - and why I think they don't demonstrate that this feature is really useful in practice. There are several examples similar to this one: class Car { public int $yearOfProduction; public string $vin; } This is either lacking a constructor to initialize the

Re: [PHP-DEV] Evolving PHP

On Fri, Sep 13, 2019, 3:10 PM Rasmus Lerdorf wrote: > Lots of drama on internals lately. Not that different from 15-20 years ago. > A couple of things to keep in mind for everyone. > > It is not that hard to write a tool that perfectly fits your own needs and > people who are very similar to you

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

Though this is truly a stylistic complaint, I think it will lead to harder-to-analyse code. Currently I have a static analysis tool that can verify (in 99% of cases) whether all properties of a class have been initialised in the constructor. This check is even more important in PHP 7.4, where use

[PHP-DEV] Evolving PHP

Lots of drama on internals lately. Not that different from 15-20 years ago. A couple of things to keep in mind for everyone. It is not that hard to write a tool that perfectly fits your own needs and people who are very similar to you in terms of skillset, background and overall experience. What

Re: [PHP-DEV] Evolving PHP

Am 13.09.2019 um 16:10 schrieb Rasmus Lerdorf : > The people writing the code get to call the shots, for better or worse. There's some caveats with this: 1) What does "write the code" mean? What is the threshold when I can take over a project? 2) With a bigger user-base there is also bigger

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

Hi Rasmus, On Fri, 13 Sep 2019 at 11:18, Rasmus Schultz wrote: > All in all, I find this feature is useful or applicable only to a few, > select patterns within the language - it isn't general enough. > I've trimmed the quote for readability, but agree with basically everything in this

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

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

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

> Le 13 sept. 2019 à 07:49, Michał Brzuchalski a > écrit : > > Hi Lynn, > > czw., 12 wrz 2019 o 17:01 Lynn mailto:kja...@gmail.com>> > 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

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

Hi Michal, > https://wiki.php.net/rfc/object-initializer I recently joined this list again after many years away, and a primary reason was to eventually propose an RFC that is almost exactly what you are calling Object Initializers. So a huge thumbs up on this RFC. Kudos. I wish I had a

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

Hi Claude, pt., 13 wrz 2019 o 08:39 Claude Pache napisał(a): > > > Le 13 sept. 2019 à 07:49, Michał Brzuchalski > a écrit : > > 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

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

> What's the added benefit of this compared to implementing a constructor? Michal my have a different answer but my answer are the following two benefits plus a 3rd related benefit: 1. The ability to add strictness to object initialization vs. using arrays of properties. PHP itself could flag

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

> That said, I generally use arrays rather than DTO objects I too have often used arrays. But then I have always been rigorous to ensure that variables and array elements are initialized before use, and fortunately I do not have a lot of typos in code I write. However I recently took on a

Re: [PHP-DEV] Changing fundamental language behaviors

On 12/09/2019 23:16, Mike Schinkel wrote: 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

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

Hi Olumide, czw., 12 wrz 2019 o 17:07 Olumide Samson napisał(a): > 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 >

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

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

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

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

Re: [PHP-DEV] Changing fundamental language behaviors

Am 13.09.2019 um 09:41 schrieb Lester Caine : > On 12/09/2019 23:16, Mike Schinkel wrote: >> Those who vote on this list will decide if breaking WordPress end-user's >> site bothers them or not. That's something too few people on this list seem to be aware of: Breaking other people's perfectly

Re: [PHP-DEV] Changing fundamental language behaviors

> Upgrading the ~68,000 open source plugins available on wordpress.org > , thousands of commercial plugins, and and an untold > number of custom-developed bespoke plugins and custom themes is where the > concern lies. Many of these are ticking bombs - unmaintained

Re: [PHP-DEV] Changing fundamental language behaviors

On Fri, Sep 13, 2019 at 10:10 AM Christian Schneider wrote: > Am 13.09.2019 um 09:41 schrieb Lester Caine : > > On 12/09/2019 23:16, Mike Schinkel wrote: > >> Those who vote on this list will decide if breaking WordPress > end-user's site bothers them or not. > > That's something too few people

Re: [PHP-DEV] Changing fundamental language behaviors

Hello Zeev Would you mind sharing with us why you specifically would be able to single handedly decide what gets merged into PHP and what not? Kind regards Brent On 13 Sep 2019, 01:56 +0200, Zeev Suraski , wrote: > > > On 13 Sep 2019, at 2:50, Joe Watkins wrote: > > > > Zeev, > > > > > Without

Re: [PHP-DEV] Changing fundamental language behaviors

On 13/09/2019 09:10, Christian Schneider wrote: Is it really worth it? It's absolutely worth it. Stopping execution flow at erroneous or ambiguous statements is an essential part of secure, reliable programming. A notice or warning offers no protection at all. Unless you've taken some very

[PHP-DEV] Offtopic discussions

Hello all I've noticed a trend in many threads here on the internals list where an RFC is being discussed, but one way or another we always end up with the same offtopic conversation about how PHP should evolve. While I think this is a good conversation to have, I don't think it's beneficial

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

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

Re: [PHP-DEV] Offtopic discussions

On Fri, 13 Sep 2019 at 09:30, Brent wrote: > Hello all > > I've noticed a trend in many threads here on the internals list where an > RFC is being discussed, but one way or another we always end up with the > same offtopic conversation about how PHP should evolve. While I think this > is a good

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

This can easily be done in a number of ways, like the suggested helper function. The same can be said for many other features that were implemented recently, like array unpacking. This feature is easy to implement and will make the code for data objects much more readable, with additional benefits

Re: [PHP-DEV] Changing fundamental language behaviors

> Many of these are ticking bombs - unmaintained extensions with possible > security issues. Totally agree. > Right now the biggest problem of WordPress ecosystem is quality of community > extensions and themes. Being intimately involved in the WordPress ecosystem, I do not know If it is the

Re: [PHP-DEV] Changing fundamental language behaviors

I'm thinking this thread is receiving much attention than really required. Irrespective of the left and right argument, I think everyone wants a better language, the leftist are just arguing on a very lazy fact, not that they don't see anything bad in their wrong argument they are all just trying

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

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

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

Arnold, > This can easily be done in a number of ways, like the suggested helper > function. A helper function can simulate an object initializer but it cannot provide the same potential benefits. The helper function uses array keys to identify properties, and as array keys cannot be

Re: [PHP-DEV] Changing fundamental language behaviors

> On 13 Sep 2019, at 15:28, Mark Randall wrote: > > the notion of > > declare(sloppy=1); > > Has already been jokingly proposed, Who ever said it was a joke proposal? :-P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php