Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111164
MIME-Version: 1.0
References: <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
 <CAOsHV+sqKjOCSH80xWg8ywWCFGK24p7fKtNsCztu6B5ETL9_aQ@mail.gmail.com>
In-Reply-To: <CAOsHV+sqKjOCSH80xWg8ywWCFGK24p7fKtNsCztu6B5ETL9_aQ@mail.gmail.com>
Date: Fri, 24 Jul 2020 13:26:01 +0100
Message-ID: <CABHuAWwoYXcnzRNBfT3-zDbJ9h89LT90GYT=j_2tvmmFWfq9Hg@mail.gmail.com>
To: Marcio Almada <marcio.web2@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001d37cb05ab2f1443"
Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters
From: t.carnage@gmail.com (Chris Riley)

--0000000000001d37cb05ab2f1443
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 24 Jul 2020 at 13:05, Marcio Almada <marcio.web2@gmail.com> wrote:

> Hi
>
> >
> > Hi all,
> >
> > The named parameters RFC has been accepted, despite significant
> objections
> > from maintainers of larger OSS projects due to the overhead it adds to
> > maintaining backwards compatibility as it has now made method/function
> > parameter names part of the API; a change to them would cause a BC brea=
k
> > for any library users who decide to use the new feature.
> >
> > It is likely that the way this will shake out is that some maintainers
> will
> > accept the additional overhead of including parameter names in their BC
> > guidelines and others will not, this leaves users unsure if they can us=
e
> > the new feature without storing up issues in potentially minor/security
> > releases of the libraries they use. This is not really an ideal
> situation.
> >
> > More pressing a point is that the current implementation breaks object
> > polymorphism. Consider this example (simplified from one of my codebase=
s)
> >
> > interface Handler {
> >     public function handle($message);
> > }
> >
> > class RegistrationHandler implements Handler {
> >     public function handle($registraionCommand);
> > }
> >
> > class ForgottenPasswordHandler implements Handler {
> >     public function handle($forgottenPasswordCommand);
> > }
> >
> > class MessageBus {
> >     //...
> >     public function addHandler(string $message, Handler $handler) {
> //... }
> >     public function getHandler(string $messageType): Handler { //... }
> >     public function dispatch($message)
> >     {
> >         $this->getHandler(get_class($message))->handle(message:
> $message);
> >     }
> > }
> >
> > This code breaks at run time.
> >
> > Proposals were made for resolutions to this issue however all of them
> > require trade offs and could potentially break existing code.
> >
> > My proposal to resolve these two issues is to add the ability to rename
> > parameters with a new syntax as follows.
> >
> > function callBar(Foo $internalName:externalName) {
> >     $internalName->bar();
> > }
> >
> > $x =3D new Foo();
> > callBar(externalName: $x);
> >
> > This allows both the above problems to be resolved, by renaming the
> > internal parameter and keeping the external signature the same.
> >
> > I propose that the RFC would have two voting options.
> >
> > The first would be to implement it as proposed above, this would allow
> any
> > parameter to be called by name regardless of the intentions of the auth=
or
> > of the method/function and is closest to the current behaviour.
> >
> > The second option would be to use this syntax to make named parameters =
in
> > userland code explicitly opt in. As such an additional shortcut syntax
> > would be implemented: $: to designate a named parameter. eg
> >
> > function callBar($:externalName) {
> >     $externalName->bar();
> > }
> >
> > $x =3D new Foo();
> > callBar(externalName: $x);
> >
> > If a parameter is not opted in, a compile time error is raised:
> >
> > function callBar($externalName) {
> >     $externalName->bar();
> > }
> >
> > $x =3D new Foo();
> > callBar(externalName: $x); // Error: cannot call parameter $externalNam=
e
> by
> > name.
> >
> > There are pros and cons to this second approach, on the one hand it
> reduces
> > the usefulness of the named parameter syntax by requiring changes to ol=
d
> > code to enable it (although this could probably be automated fairly
> easily)
> > however it does provide a neater solution to the second problem in that=
,
> to
> > prevent the runtime errors in the second issue example, every child cla=
ss
> > would need to use the rename syntax on it's parameter to prevent errors=
,
> > whereas if we went down this route, the parent class could just not opt
> > into the named parameter syntax and the code would function as expected=
.
> >
> > Another advantage is that with the ability to rename parameters using t=
he
> > opt in, we gain some flexibility to tighten up the LSP rules relating t=
o
> > named parameter inheritance.
> >
> > class Foo {
> >     public function bar($:param) { //... }
> >     public function baz($internal:external) { //... }
> > }
> >
> > // OK
> > class Bar {
> >     public function bar($renamed:param) { //... }
> >     public function baz($renamed:external) { //... }
> > }
> >
> > // Compile time error cannot rename named parameter $:param (renamed to
> > $:renamedParam)
> > class Baz {
> >     public function bar($:renamedParam) { //... }
> > }
> >
> > // Compile time error cannot rename named parameter $:external (renamed
> to
> > $:renamed)
> > class Baz {
> >     public function baz($internal:renamed) { //... }
> > }
> >
> > While this would be technically possible with the first option (no opt
> in)
> > it would break any existing code which renames a parameter as every
> > parameter would be subject to these rules.
> >
> > I don't have Wiki karma so can't post this yet; but I want to get the
> ball
> > rolling on discussion as feature freeze is coming up fast and if we wan=
t
> to
> > go for the second option, that must hit before the named parameter synt=
ax
> > is in a tagged version of PHP.
> >
> > Regards,
> > Chris
>
> For reference, I believe you are proposing something
> close to Swift external names but way more complex.
>
> Ty,
> M=C3=A1rcio
>

Hi,

I've never written any code in swift, however having quickly read the
documentation I think that my proposal is almost identical to swift
argument labels if the first option is chosen. It's interesting to note
that swift provides an explicit opt out of named parameters instead of an
opt in (by giving it a _ for it's external name) this could be an
alternative option for this RFC, although I'd propose the $: syntax in that
instance. You'd lose the ability to do compile time checks on parameter
renames in child classes; but it might provide a pragmatic middle ground
between my two proposed options.

Thanks,
Chris

--0000000000001d37cb05ab2f1443--