Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111166
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 15:01:32 +0200
Message-ID: <CAEPJdunD+fXeSLUB6HXdH6eKWThiukvwOM6y4i-KH4DCUVL8qg@mail.gmail.com>
To: Chris Riley <t.carnage@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000025892905ab2f9323"
Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters
From: kontakt@beberlei.de (Benjamin Eberlei)

--00000000000025892905ab2f9323
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 24, 2020 at 1:13 PM Chris Riley <t.carnage@gmail.com> wrote:

> 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 break
> for any library users who decide to use the new feature.
>

Hi Chris,

I had something similar in mind, but using an attribute. Here is a patch
that already allows this:

https://github.com/beberlei/php-src/commit/4b0a02f9c6ba579f93ec57c754fa3794a96c696b

Idea: Have a @@NameAlias attribute, where you can provide a second name for
the attribute. This would allow to refactor parameter names by adding the
attribute with the old name as an alias.


>
> 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 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 = 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 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 = new Foo();
> callBar(externalName: $x);
>
> If a parameter is not opted in, a compile time error is raised:
>
> function callBar($externalName) {
>     $externalName->bar();
> }
>
> $x = 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 reduces
> the usefulness of the named parameter syntax by requiring changes to old
> 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 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 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 want to
> go for the second option, that must hit before the named parameter syntax
> is in a tagged version of PHP.
>
> Regards,
> Chris
>

--00000000000025892905ab2f9323--