Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111395 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 45551 invoked from network); 9 Aug 2020 18:27:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Aug 2020 18:27:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7AE8A1804E3 for ; Sun, 9 Aug 2020 10:25:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 9 Aug 2020 10:25:55 -0700 (PDT) Received: by mail-lj1-f173.google.com with SMTP id 185so7169855ljj.7 for ; Sun, 09 Aug 2020 10:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AIkqNj3o0fJVW/RYzmLJcdgdh30fcEejtn9+bO7TyVo=; b=dRogZcBx2fbKyFRHy90Jo6DKTcH2ghKPE+h+SmZ74m7qUOn3DQP0tP5W+wR4hYe4o0 RzRIYDKUp2+LK1515PnODL3aUejzLDyRHNz9S9/dQ45lS2bHD7DTFv3HFO0APbF5lH19 +2xZEs1NGWP1BEn0QG+xf9JjBbustpRnfrehiM/ZSnfcTNpX8GePOv9BJoFVz+LEzG3f zx8BxxAavVq1Djvn1Fl3ouYSMfnj7DoU8kRkOHmDvy1ttYCXiJZvnDVq8Cvj+KflFzZm txmUC0TEI5K29JcMYxsdlHTI1emBj3FKPbWCaGAgxsnbm+eFjHEZju0oKzYMavPFa7zu /6rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AIkqNj3o0fJVW/RYzmLJcdgdh30fcEejtn9+bO7TyVo=; b=mwiJ4OMS4JnA1H1miumbr4Gt+IgDon5P9NHAkJjgFMD1vK7NedCGgDr8OHheJ+MEEZ lLtHoI7ycDVPwCRd34qz1tGpP4+PnkYVOdYpNrdYS8jIXG8brIXJgmpI/4ROoALjwuWD W7GASqNQjsZy3MoJzKGOEMT4YcVIeDLiByr9wBRdVtadTFp3R/O7gxw6nnD9OsqfPd0N TzZ2nrKvpHEEfPiUrnhxhVDg0Qs893y96KF2l3LVg4rXTScy5Gl79P1DkIekzeqgYS7+ qV9tNtV1Qx5u5Gwy1ONoWt2mdT+72ANgCfSlCV4p4dCLyipwaLpNOdFNfswQesF1mREZ VI9w== X-Gm-Message-State: AOAM532pmzNhGmDIjPPIXophc+iojeWgXNkLuERX0SLNogLbzu+ZyUYF EfSdSFEIHdqKhzc5mCqHBjBdEdKNaUvwyxu5yuE= X-Google-Smtp-Source: ABdhPJx2ZW1oD2rzOwI5RgVHMMwMcisdXttUfCeel0m5nokpJb9UcArLtQX8d23V1EejjvzOwdubyyi0MwTvhMOewEI= X-Received: by 2002:a2e:5811:: with SMTP id m17mr10677630ljb.96.1596993952545; Sun, 09 Aug 2020 10:25:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 9 Aug 2020 20:25:37 +0300 Message-ID: To: Chris Riley Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000003ffd6b05ac7521ca" Subject: Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters From: benas.molis.iml@gmail.com (Benas IML) --0000000000003ffd6b05ac7521ca Content-Type: text/plain; charset="UTF-8" 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 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 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 > > > --0000000000003ffd6b05ac7521ca--