Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110023
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
In-Reply-To: <CAF+90c8MQgXwNGsx8zcgkYWBkmJEO7wCum-6+yyAYt=yC_+_-A@mail.gmail.com>
Date: Tue, 5 May 2020 15:43:26 -0400
Cc: Marco Pivetta <ocramius@gmail.com>,
 Theodore Brown <theodorejb@outlook.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5C52A68A-482E-4F1E-A6C6-158A25D5901A@zort.net>
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>
 <CAF+90c8MQgXwNGsx8zcgkYWBkmJEO7wCum-6+yyAYt=yC_+_-A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: jbafford@zort.net (John Bafford)

On May 5, 2020, at 14:21, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> Another is to allow specifying the public parameter name and the =
private
> parameter variable name separately, as is possible in Swift. This =
would
> allow changing "parameter" names arbitrarily, without breaking the =
public
> API. This would be a pretty direct counter to your concern, but I'm =
not
> really sure that your concern is important enough to warrant the =
additional
> weight in language complexity. I've never used Swift myself, so maybe =
this
> is actually awesome and I just don't know it.
>=20
> Regards,
> Nikita

The proposal in my earlier email is very much inspired from Swift. I =
think having distinct outside and inside names helps greatly with =
creating expressive and readable APIs. The most expressive name for a =
thing might differ greatly between inside and outside contexts. Also, =
the name of a parameter as used by the inside of a function should be an =
implementation detail; there's no reason it should have to be exposed to =
the outside.

For example, Swift's Array has the following two methods (slightly =
simplified):

	func firstIndex(of element: Element) -> Int?
	func firstIndex(where predicate: (Element)  -> Bool) -> Int?

You call them like:

	array.firstIndex(of: someElement)
	array.firstIndex(where: { $0 =3D=3D someElement })

=46rom the outside, firstIndex(of: ...) is more readable than =
firstIndex(element: ...) because it reads more like natural language. =
Same with firstIndex(where: ...) vs. firstIndex(predicate: ...). On the =
inside, calling it "element" and "predicate" help you focus on what it =
_is_, without worrying about calling it something that also retains =
meaning to callers.

If you at some point decided to have a mass-renaming of "predicate" to =
"test", you could change that everywhere in your library without forcing =
any sort of change to users, because predicate is "on the inside". And =
both of them starting with 'firstIndex(' gives them a clear =
relationship; they generally do the same thing, just with a type of =
input.

With php currently, you would probably implement those as:

	function firstIndexOfElement($element)
	function firstIndexWithPredicate($predicate)

	$collection->firstIndexOfElement($element);
	$collection->firstIndexWithPredicate($someCallable);

But I think that's more wordy, and now you have either a BC break or =
need to add a new function if you decided to rename all instances of =
"predicate" to "test".

A more readable API might look like this:

	$collection->firstIndex(of: $element);
	$collection->firstIndex(where: $someCallback);

which is less typing, presuming your IDE didn't offer autocomplete for =
you anyway.

-John