Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111173 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23446 invoked from network); 24 Jul 2020 15:17:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Jul 2020 15:17:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 192AC1804D2 for ; Fri, 24 Jul 2020 07:12:13 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 ; Fri, 24 Jul 2020 07:12:12 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id t142so2033746wmt.4 for ; Fri, 24 Jul 2020 07:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beberlei-de.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pScT18FI7/eNOoQa1jeF1YzUAzHV9cuWA2uVK8IPVNE=; b=gWGDZVyS72osKn8NeUVoCaZwj0sDSJlkEbz7uR1+m2Imn9KOEqoiDMUK4cwsW0tl/a Y//1kbt2GjQtSO6mcTU0qqwgwJ3xBJzNZRUa8nXxsiBvOi2GOGn7/W+EEiNQ+CrXM68p +N4h93Z0yFxvX935JYjWuahIGOnoAYH+TzTRwqO5hpIm8cZlU1/03vXgYGE87SmHa4Fj apDNG0verK22iI4C5imdIaAQtXjFa8eP5yhu2UNyKeaa/1Xw2IC6tVKnUc2Rosqr8/WV jwCYbx43aaa+KA5SjQlglSZfKW3NNwqdlHvd6pdCadfd6E+KDXFjJoGiKgAoT/Gg7mgz c5nA== 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=pScT18FI7/eNOoQa1jeF1YzUAzHV9cuWA2uVK8IPVNE=; b=uF1ZTS2nriLL7QuRfRa1WfrQaXE3mpAs5Sapn/B+yyDZyObQ2N+bMpuvsnHMj1JREC g29M6mffopPaa18LLrT9DVedR8lPGNYtohWWiPIh6XrffMNfv2P8rOVuEMq4f2cMDpfj FyjLLs11OX1bilJ8deohl3EFGCbIn46hoydhcsXRNd3slU3X5CQvCYlsGTHEEZbbBgOY YT9597b30Cj89kz2Sx/Pumz95WNCm+8b0woUqx8mg/vGXsdDkw2nRa9QY9a6w/1FPsBg H8NYNeEtTx1LCKmAw8ety9DQWXFLDBHfi1gjZeiaxlKtdJidj7eWdZbfHqzlrAPdpHIA kumQ== X-Gm-Message-State: AOAM531gab43aeZVmH3Bm4Vbf8PfBW9QZqAJpw5S9CPFDB3s2ckeKE1+ YkgdyKn4lnsMUKBQk0QB5eEayGSky/6uiG5FQIwHrg== X-Google-Smtp-Source: ABdhPJwNRCrRi8LL00QDx/d9glVpzUtuKoauVF5a/dS9Revr9tqHNUVvIOuvfV044nvSaMHpQjUkyg/ZxysedCq2gPA= X-Received: by 2002:a05:600c:2309:: with SMTP id 9mr2458147wmo.107.1595599924391; Fri, 24 Jul 2020 07:12:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 24 Jul 2020 16:11:53 +0200 Message-ID: To: Chris Riley Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000b2949805ab308e61" Subject: Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000b2949805ab308e61 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 24, 2020 at 4:00 PM Chris Riley wrote: > Hi all, > > Following up from this I've created a draft RFC: > https://wiki.php.net/rfc/renamed_parameters will move to in discussion > once > I've ensured everything important has been captured. > > Regards, > Chris > You added PHP 8.0 as a propsoed version, but that will not be possible anymore 2 weeks of discussion + 2 weeks of voting are not possible to fit in before the feature freeze, which is in 11 days. > > 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 > > > --000000000000b2949805ab308e61--