Re: [PHP-DEV] [RFC] [VOTE] Compact Object Property Assignment

On Tue, 31 Mar 2020 at 03:24, Jakob Givoni wrote: > > I've moved the RFC to the voting phase: > > https://wiki.php.net/rfc/compact-object-property-assignment Hi Jakob, Please don't forget to send a separate email announcing the voting with a separate subject. "Send an email to

[PHP-DEV] [RFC] [VOTE] Compact Object Property Assignment

Heads up! I've moved the RFC to the voting phase: https://wiki.php.net/rfc/compact-object-property-assignment Voting is open until the end of Monday, April 13 (your time zone :-). Good night, Jakob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

Hi Larry! I have a lot of respect for the vision you're working on. Great advances sometimes come out of great visions. But let's not forget that so far it's only a vision and not all visions come to fruition. We don't know - at the moment it's anybody's guess. At this point I hardly expect you

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

> I have already told you that the output of this function was never meant > for human consumption. > It was originally added to aid in caching of larger complicated data > structure through the likes of apc's opcode cache. It is sometimes used for human consumption now, though. For example, my

Re: [PHP-DEV] [RFC] switch expression

Hi Larry > Not everything has to be a statement. This is not what I meant. What I meant is that it should be usable in a statement context. Since you mentioned Rust, match is always an expression. But you can use it without making use of the return value. This is what I'm suggesting. In PHP this

Re: [PHP-DEV] [RFC] switch expression

On Sun, Mar 29, 2020, at 5:07 PM, Ilija Tovilo wrote: > Hi Larry > > Thanks for your suggestion. > > I chose to use switch instead of match for a couple of reasons: > > 1. It uses the same AST, code generation and opcodes as the switch, I > don't agree that it is significantly different than

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, 30 Mar 2020, Sherif Ramadan wrote: > Given that code is meant for human consumption I have already told you that the output of this function was never meant for human consumption. It was originally added to aid in caching of larger complicated data structure through the likes of apc's

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 12:38 PM Chase Peeler wrote: > Just out of curiosity, is there any reason we couldn't add an optional > parameter called "$short_array" or whatever that defaults to false? Then > there shouldn't be any backwards compatibility issues. > > None at all, though I'd make it an

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, 30 Mar 2020, Chase Peeler wrote: > Just out of curiosity, is there any reason we couldn't add an optional > parameter called "$short_array" or whatever that defaults to false? > Then there shouldn't be any backwards compatibility issues. And then you'd have to maintain two behaviours,

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 1:32 PM Sara Golemon wrote: > On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel > wrote: > > > If "they" don't care about syntax, then why do you? > > > > > > Sorry I was unclear. I was reacting to the argument about broken tests in > > php-src. > > I meant: they don't

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 12:32 PM Sherif Ramadan wrote: > Now, will you answer my question? >> > > Simple. > Wrong. It's complex as this thread proves. Opinions are not in alignment making it non-simple. > Because an implement in php-src is more available, > Wrong. It's got availability FOR

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

On Sun, Mar 29, 2020 at 11:31 PM Jakob Givoni wrote: > > Hi Rowan, > > On Sat, Mar 28, 2020 at 4:01 PM Rowan Tommins wrote: > > > > While I'd personally be fine with this change, I think we should > > understand why the previous proposal failed rather than just hoping the > > vote goes

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 11:39 AM Benjamin Morel wrote: > If "they" don't care about syntax, then why do you? > > > Sorry I was unclear. I was reacting to the argument about broken tests in > php-src. > I meant: they don't have *expectations* about the syntax, but they'll most > likely want to be

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 1:19 PM Sara Golemon wrote: > On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan > wrote: > >> @Sara Golemon >> >> >>> Ditto Danack's question, adding: "Then why not use brick/varexporter?" >>> >>> -Sara >>> >> >> I punt the question back to you and ask why not use PHP? >>

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 10:56 AM Sherif Ramadan wrote: > @Sara Golemon > > >> Ditto Danack's question, adding: "Then why not use brick/varexporter?" >> >> -Sara >> > > I punt the question back to you and ask why not use PHP? > > Simple. Because an implementation in script code is more agile,

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

> > If "they" don't care about syntax, then why do you? Sorry I was unclear. I was reacting to the argument about broken tests in php-src. I meant: they don't have *expectations* about the syntax, but they'll most likely want to be able to read it. — Benjamin

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

> > > Aesthetics are irrelevant for a computer. > > This change does not improve anything and only breaks compatibility. Bad > idea. > > I beg to differ. While code may be meant for execution by a machine it is actually intended for human consumption. Aesthetics matter to a human reading the code.

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On 30 March 2020 16:54:55 BST, Sherif Ramadan wrote: >@Dan Ackroyd > >> Is there any reason to do this change other than aesthetic choice? >> >> >Just because it is aesthetic is not actually an argument against. Why >wouldn't you want to improve the aesthetics of PHP? Is it only an >aesthetic

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

@Sara Golemon > Ditto Danack's question, adding: "Then why not use brick/varexporter?" > > -Sara > I punt the question back to you and ask why not use PHP?

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

@Dan Ackroyd > That's an aesthetic choice, which not everyone will agree with. > Yes, I freely state that in the RFC. Everyone is free to vote how they like. > > "There shouldn't be any backwards incompatible changes" > > It apparently breaks 25 tests that compare the output of var_export >

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

Am 30.03.20 um 16:39 schrieb Sara Golemon: >> I don't see a reason not to follow with the short array syntax; the only >>> expectation of people using var_export(), AFAIK, is to get valid PHP code; >>> they don't care about the syntax, >> > If "they" don't care about syntax, then why do you? The

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Mon, Mar 30, 2020 at 9:06 AM Benjamin Morel wrote: > I don't see a reason not to follow with the short array syntax; the only >> expectation of people using var_export(), AFAIK, is to get valid PHP code; >> they don't care about the syntax, > > If "they" don't care about syntax, then why do

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

> > "Then why not use brick/varexporter?" As much as I'm pleased that people use this library, I consider it a shim, waiting for PHP to ultimately provide the same functionality. See the (object) cast for stdClass, that was supported by varexporter but was later added to var_export(). I don't

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Sun, Mar 29, 2020 at 3:43 PM Benjamin Morel wrote: > This is the syntax I'm using in brick/varexporter > , and supporting it natively in > var_export() makes sense. > > Ditto Danack's question, adding: "Then why not use brick/varexporter?" -Sara

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

Hi Levi, On Sun, Mar 29, 2020 at 8:06 PM Levi Morrison wrHote: > > The current RFC text is not consistent with using `=` or `=>` for the > assignments. The assignment `=` is vastly more common, though, and I > don't understand why if we are using an array syntax we aren't using > `=>`. Not sure

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

On Sun, 29 Mar 2020 at 18:51, Sherif Ramadan wrote: > > I'm proposing a new RFC to change var_export()'s array syntax to use the > short hand array syntax instead. > "The old array() construct is a kludge and is unappealing." That's an aesthetic choice, which not everyone will agree with.

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

Hi Jakob, On Sun, 29 Mar 2020 at 21:57, Jakob Givoni wrote: > > I understand and fully agree that COPA is narrow, but I don't really > understand why that's a problem - I proposed it exactly because I felt that > its simplicity is its force. > Low hanging fruit is usually something I would

Re: [PHP-DEV] Interfaces and ReflectionMethod::isConstructor()

Am 30.03.2020 um 10:14 schrieb Marco Pivetta: Patch makes a lot of sense, but is it done that way to still support 7.x? I'm not sure (don't have a local build of PHP 8.x-dev) if https://wiki.php.net/rfc/remove_php4_constructors is going to come in effect as "PHP4 constructors are finally gone".

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

On Mon, Mar 30, 2020 at 3:06 AM Levi Morrison via internals < internals@lists.php.net> wrote: > The current RFC text is not consistent with using `=` or `=>` for the > assignments. The assignment `=` is vastly more common, though, and I > don't understand why if we are using an array syntax we

Re: [PHP-DEV] Interfaces and ReflectionMethod::isConstructor()

Hey Sebastian, On Mon, Mar 30, 2020 at 8:45 AM Sebastian Bergmann wrote: > Am 28.03.2020 um 08:44 schrieb Sebastian Bergmann: > > I can deal with this in PHPUnit's code either way, but need to know what > > the plan here is. > > I worked around the issue now [1].

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

On Sun, Mar 29, 2020 at 12:07 AM Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: > Hi all PHP gurus! > > This is a feature request / RFC for the following use-case: > > $res = []; > foreach ($arr as $i) { > foreach (make_res($i) as $v) { > $res[] = $v; > } > } > > Array_merge in loop is

Re: [PHP-DEV] Interfaces and ReflectionMethod::isConstructor()

Am 28.03.2020 um 08:44 schrieb Sebastian Bergmann: I can deal with this in PHPUnit's code either way, but need to know what the plan here is. I worked around the issue now [1]. -- [1] https://github.com/sebastianbergmann/phpunit/commit/477798f6b226e830d358bc102cd02bb2e52cfdb2 -- PHP