Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111163
MIME-Version: 1.0
References: <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
In-Reply-To: <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
Date: Fri, 24 Jul 2020 09:04:50 -0300
Message-ID: <CAOsHV+sqKjOCSH80xWg8ywWCFGK24p7fKtNsCztu6B5ETL9_aQ@mail.gmail.com>
To: Chris Riley <t.carnage@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters
From: marcio.web2@gmail.com (Marcio Almada)

Hi

>
> Hi all,
>
> The named parameters RFC has been accepted, despite significant objection=
s
> 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 break
> 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 wi=
ll
> accept the additional overhead of including parameter names in their BC
> guidelines and others will not, this leaves users unsure if they can use
> 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 codebases)
>
> 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 an=
y
> parameter to be called by name regardless of the intentions of the author
> 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 $externalName =
by
> name.
>
> There are pros and cons to this second approach, on the one hand it reduc=
es
> the usefulness of the named parameter syntax by requiring changes to old
> code to enable it (although this could probably be automated fairly easil=
y)
> 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 class
> 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 the
> opt in, we gain some flexibility to tighten up the LSP rules relating to
> 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 t=
o
> $: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 bal=
l
> rolling on discussion as feature freeze is coming up fast and if we want =
to
> go for the second option, that must hit before the named parameter syntax
> 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