Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111396
MIME-Version: 1.0
References: <CABHuAWx16_6rwye6BC4gUctSEdTTV0bq68S=1znNPykwGzXTsQ@mail.gmail.com>
 <CABHuAWx7kXPdWRh1Wb1Es52vEunzCw3_oNk523LwR_BXqunFOQ@mail.gmail.com> <CANeKSiTuVKj4YwuCHBuTH9PbzCrbEbz1msSs5XGat4Z9+w1L_w@mail.gmail.com>
In-Reply-To: <CANeKSiTuVKj4YwuCHBuTH9PbzCrbEbz1msSs5XGat4Z9+w1L_w@mail.gmail.com>
Date: Sun, 9 Aug 2020 20:26:52 +0300
Message-ID: <CANeKSiTNmGue13kTAWKW-Oh881-fk4vfM02V_tiQ1L8oPisD7A@mail.gmail.com>
To: Chris Riley <t.carnage@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aa5d3205ac752572"
Subject: Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000aa5d3205ac752572
Content-Type: text/plain; charset="UTF-8"

After sending out the email, I found out that I replied to the wrong email,
nevermind... Sorry about that!

Best regards,
Benas

On Sun, Aug 9, 2020, 8:25 PM Benas IML <benas.molis.iml@gmail.com> wrote:

> Hey Chris,
>
> thanks for the RFC but I'd like to remind you that we are already past the
> feature freeze. Moreover, it seems that you don't have an actual
> implementation as well.
>
> Best regards,
> Benas
>
>
> On Sun, Aug 9, 2020, 8:15 PM Chris Riley <t.carnage@gmail.com> wrote:
>
>> Hi all,
>>
>> RFC link: https://wiki.php.net/rfc/renamed_parameters
>>
>> I have spent the weekend working on a final revision for this RFC to
>> address several of the points brought up. Specifically:
>>
>> - Cut down the scope of the RFC to only focus on delivering an opt in to
>> named parameters, with the renaming ability explicitly pushed into future
>> scope as opposed to leaving it to the RM discretion. This will allow a
>> fuller discussion on how best to support renaming going forward, be it
>> using my proposed syntax or using attributes.
>> - Focused in on the technical issues as opposed to subjective arguments
>> for/against.
>> - Added additional example of the polymorphism problem when it comes to
>> the
>> behaviour of variadics, which didn't seem to come up in the original RFC.
>> - Added resolution on dealing with the PHP standard library, as this is an
>> enhancement to the original named parameters RFC, this RFC proposes to opt
>> in the PHP standard library. There are a couple of minor changes to
>> behaviour for classes which extend built ins to make upgrading smoother.
>> - Clarified changes to reflection parameter
>> - Added alternative implementation option using attributes which will be
>> the subject of an additional voting option for those who would prefer to
>> go
>> down this route.
>>
>> I think the RFC now represents a concrete problem and solution suitable
>> for
>> voting on, but I'm going to leave discussion open for a few days in case
>> anyone has any queries on the revisions.
>>
>> Regards,
>> Chris
>>
>>
>> On Fri, 24 Jul 2020 at 12:12, 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.
>> >
>> > 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
>> >
>>
>

--000000000000aa5d3205ac752572--