Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

This is only part of a thread. view whole thread
  105096
April 5, 2019 08:30 michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
pt., 5 kwi 2019 o 08:56 CHU Zhaowei <me@jhdxr.com> napisał(a):

> Here is a MDN document for spread operator in JS: > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals > and hope you find more useful examples. >
The next paragraph in MDN document is spread operator for object literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals Now JavaScript objects can be used like our array with keys and I simply don't understand why we cannot preserve keys, like in JS object literals Sample code: JavaScript: var a = {foo: true, ...{bar: "baz"}}; // become {foo: true, bar: "baz"} and you can access it via a.foo or as an array dimension a['foo'] - more or less like PHP arrays, right with key as a dimenrsion in array Your RFC covers: PHP: $a = [1, 2, 3, ...[4, 5, 6]]; // resulting [1, 2, 3, 4, 5, 6] What would happen in: a) PHP: $a = ['foo' => true, ...[4, 5, 6]]; // ?? b) PHP $a = ['foo' => true, ...['bar' => 'baz']] // error ?? Don't get me wrong I just see spread operator in function arguments a different feature which allows working with variadic parameters, and we're talking about the different feature here which only use the same operator, right?
  105098
April 5, 2019 08:50 rowan.collins@gmail.com (Rowan Collins)
On Fri, 5 Apr 2019 at 09:31, Michał Brzuchalski <michal@brzuchalski.com>
wrote:

> The next paragraph in MDN document is spread operator for object literals > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals > Now JavaScript objects can be used like our array with keys and I simply > don't understand why we cannot preserve keys, like in JS object literals >
The original draft discussed this, but there wasn't agreement on how identical keys should be handled, e.g.: $a = ['foo' => 1, ...['foo' => 2]] Should $['foo'] be 1 or 2? Cases were made for both, and it was pointed out that if we get named arguments, the argument spread operator will need to work the same way as whatever is decided for arrays. So the current approach is to get integer keys working first, using the same behaviour as for parameters, and then revisit string keys later. Regards, -- Rowan Collins [IMSoP]
  105101
April 5, 2019 09:00 michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
pt., 5 kwi 2019 o 10:50 Rowan Collins collins@gmail.com> napisał(a):

> > The original draft discussed this, but there wasn't agreement on how > identical keys should be handled, e.g.: > > $a = ['foo' => 1, ...['foo' => 2]] > > Should $['foo'] be 1 or 2? Cases were made for both, and it was pointed out > that if we get named arguments, the argument spread operator will need to > work the same way as whatever is decided for arrays. > > So the current approach is to get integer keys working first, using the > same behaviour as for parameters, and then revisit string keys later. >
So we're talking about providing incomplete feature now, right? I would opt to the same behaviour as ['foo' => 1] + ['foo' => 2] // where 'foo' key results in 1 But maybe this should be optional voting for that, either way, we're delivering feature which has very limited usage which can be confusing, cause I can array_merge or use + operator so why can't I use keys with spread operator if I already have them in my generator, iterable or array which came from for eg. json_decode or whatever. -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com
  105103
April 5, 2019 09:09 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
If we didn't provide support for string keys, we can add it back later.
If we provide this feature, and later we passed named argument with a different way to handle string keys, then it will be a huge inconsistent and difficult to fix.

Thanks,
CHU Zhaowei

-----Original Message-----
From: Michał Brzuchalski <michal@brzuchalski.com> 
Sent: Friday, April 5, 2019 5:01 PM
To: Rowan Collins collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

pt., 5 kwi 2019 o 10:50 Rowan Collins collins@gmail.com> napisał(a):

> > The original draft discussed this, but there wasn't agreement on how > identical keys should be handled, e.g.: > > $a = ['foo' => 1, ...['foo' => 2]] > > Should $['foo'] be 1 or 2? Cases were made for both, and it was > pointed out that if we get named arguments, the argument spread > operator will need to work the same way as whatever is decided for arrays. > > So the current approach is to get integer keys working first, using > the same behaviour as for parameters, and then revisit string keys later. >
So we're talking about providing incomplete feature now, right? I would opt to the same behaviour as ['foo' => 1] + ['foo' => 2] // where 'foo' key results in 1 But maybe this should be optional voting for that, either way, we're delivering feature which has very limited usage which can be confusing, cause I can array_merge or use + operator so why can't I use keys with spread operator if I already have them in my generator, iterable or array which came from for eg. json_decode or whatever. -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com
  105176
April 9, 2019 14:09 come@opensides.be (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Le vendredi 5 avril 2019, 11:00:59 CEST Michał Brzuchalski a écrit :
> So we're talking about providing incomplete feature now, right?
As I understand it, the point is to make unpacking available to arrays, to be consistent with function calls. // This is already supported $result = someFunction($a, $b, ...$array); $result = new someClass($a, $b, ...$array); // This is not $result = array($a, $b, ...$array); So when building an object I can unpack, but not when building an array, why? So the feature is designed to work the same way as for function parameters, which is why string keys are not supported, because they are not supported by the "..." operator for functions. In the end, I see that as making a feature more complete, as the "..." operator which only supported functions will now support array constructors as well. Côme