Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90743
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.80 as permitted sender)
To: "'Andrea Faulds'" <ajf@ajf.me>
Cc: "'PHP internals'" <internals@lists.php.net>
References: <3B.E6.32157.D3DFA965@pb1.pair.com>	<CAEYWF=4WxsKi6KdWtswvKUS=rQ=7A0e8qEtja9tZUoMsgwHcEw@mail.gmail.com>	<E4.B4.20254.FE84C965@pb1.pair.com> <CAEZPtU7+XjDGiw8t9ZJO99Rk+NJ2NcxZAcxvaG5KyA7B4Z5Bqg@mail.gmail.com>
In-Reply-To: <CAEZPtU7+XjDGiw8t9ZJO99Rk+NJ2NcxZAcxvaG5KyA7B4Z5Bqg@mail.gmail.com>
Date: Wed, 20 Jan 2016 22:20:12 +0100
Message-ID: <007901d153c8$5968a590$0c39f0b0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQF5QXFY8Ux0lo6aLi5M7j0z3H+IJgH0QNJRAe+VMJsC0vOlIp9/ReKw
Content-Language: de-ch
Subject: AW: [PHP-DEV] [RFC] Allow specifying keys in list()
From: php@tutteli.ch ("Robert Stoll")

Hi Andrea

I am writing you in private since I think this is rather out of scope.

 -----Urspr=C3=BCngliche Nachricht-----
> Von: Pierre Joye [mailto:pierre.php@gmail.com]
> Gesendet: Montag, 18. Januar 2016 05:54
> An: Andrea Faulds
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Allow specifying keys in list()
>=20
> hi Andrea,
>=20
> I very much like this proposal. Good work as usual!
>=20
> The only part where I think we should not rely on list is the future =
scope. I can see the logic that leads to use list for named
> arguments.
> However I really think it is a very different topic and having to use =
list to define arguments, it sounds like a hack to solve
> another long due feature.=20

I agree with Pierre on this one. Using list for named parameters seems =
like a lot of overhead on the declaration side to me (writing the name =
of a parameter twice). IMO it should not require additional effort than =
writing a function/method today and it should be available for all =
functions/methods and not only for ones with special =
named-paramater-syntax. I think you should consider further (when =
thinking about using the new feature for named parameters)
- how can you specify optional parameters?
- how can you specify byRef parameters?
- what happens if one does not provide all keys? Currently this: =
list($a, $b) =3D [1]; //only produces a Warning
- are there differences between strict mode and none strict mode?  e.g., =
what if the type of the key is different?
- would it be possible to use a type for the key as well (as for the =
value indicated in your RFC)?
- would you allow nested destructuring for parameters?
- how would you reduce the overhead of creating an array which is then =
copied and passed to the function?

IMO destructuring parameters and named parameters are two different =
things which could be combined. Something like this:
function foo(SomeClass $class, list("x" =3D> $x, "y" =3D> $y) $point =3D =
["x"=3D>0, "y"=3D>0], $flagA =3D true, $flagB =3D 1) {
}
foo($myClass, point: [1,2], flagB: 0);
foo($myClass, flagB: 2);

yet, IMO it would hamper readability (probably in many cases) and it =
would be better to do it inside the function.
I understand destructuring parameters just as syntactic sugar and I =
would still expect that PhpDocumenter would indicate that my function =
requires an array. Otherwise the same feature would suddenly also be =
used to declare deep structured data structures and at this point I am =
not so sure whether auto conversion of keys play well together with =
strict mode. It would certainly be interesting from a type safety point =
of view that one can define very complex data structures and let PHP do =
the work for verification. Yet, it also opens a door to very ugly code =
(well... which also exists without the feature) -- sorry, drifting away =
from the topic.=20

Some other points crossing my mind
- how well does the feature interact with typed arrays (if they should =
be introduced at some point)?
- how well does it interact with structural types (if they should be =
introduced at some point)?

And now some points to the RFC:
- I like the RFC in general
- I am not really a fan of the naming "list" in general but I think it =
is appropriate to reuse the same syntax for this task.
- one thing I am missing in the RFC is error handling. What happens if a =
key is not found? And there are surely other questions. I think you =
should include a section about error handling in the RFC.
- I guess mixing number keys with string keys is possible, right?
- are placeholders (something like list(_ , $a, _) =3D [1,2,3])  in your =
pipeline or do you think they make no sense in PHP?
- already an idea how it would interact with pattern matching?=20

Cheers,
Robert