Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110016
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
 <BYAPR05MB65351D7E676F6ABD5EBF3D99DEA70@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CADyq6sLgKy5xhh5f9ptV5wNEWQ7e5LwqjZc2_-8FoRtq=Yv6rA@mail.gmail.com>
In-Reply-To: <CADyq6sLgKy5xhh5f9ptV5wNEWQ7e5LwqjZc2_-8FoRtq=Yv6rA@mail.gmail.com>
Date: Tue, 5 May 2020 18:59:34 +0100
Message-ID: <CALKiJKqQHaxdd5RP0kUYxF9BMGdjKmVaLNe6YXtsrp6xVZOqqg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b41b8705a4ea696b"
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000b41b8705a4ea696b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 5 May 2020 at 18:19, Marco Pivetta <ocramius@gmail.com> wrote:

>
> I do in fact consider the `ParamNode` example in that API to be a bad
> candidate for named parameters, since I'd make all of the arguments in th=
at
> signature required anyway: defaults aren't meaningful anyway, as the AST
> library where it comes from has all the context to instantiate them all
> (the caller, being the parser, will have all the parameters anyway).
>



Parameters don't need to be optional to benefit from named syntax; they
just need to be hard to parse by a human writing (and reading!) the call.

An obvious example is PHP's needle/haystack inconsistencies that everyone
loves to hate. If all parameters were named, strpos(haystack: $content,
needle: 'hello') would be fine and I wouldn't have to look up in the manual
to check I had them in the right order.


An interesting example is network protocols originating from contexts where
parameters are named.

Take AMQP, the messaging protocol used by RabbitMQ. In PHP, you would
currently write something like this to declare a queue in no-wait mode:

$channel->queue_declare('hello', false, true, false, false, true);

In Python (or Ruby, or C#, or Elixir, or...) you can make it much more
readable *even when providing all the arguments*, and don't have to
remember what order things go in:

channel.queue_declare(queue=3D'hello', durable=3DTrue, nowait=3DTrue,
passive=3DFalse, exclusive=3DFalse, auto_delete=3DFalse)

Those aren't arbitrary names chosen by the Python client, either; they're
listed in the protocol spec:
https://www.rabbitmq.com/amqp-0-9-1-quickref.html#queue.declare

queue.declare(short reserved-1, queue-name queue, bit passive, bit durable,
bit exclusive, bit auto-delete, no-wait no-wait, table arguments) =E2=9E=94
declare-ok




Incidentally, this leads to the one part of John Bafford's counter-proposal
I would be fundamentally opposed to:

> Parameters are also positional. foo(a:..., b: ...) and foo(b: ..., a:
...) are two completely different functions, by name. If you have foo(a:b:)
defined, then you cannot call it as foo(b: ..., a: ...).

Re-ordering is, IMO, a key advantage of named parameters, so banning it
feels both arbitrary and counter-productive.



Regards,
--=20
Rowan Tommins
[IMSoP]

--000000000000b41b8705a4ea696b--