Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111167 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 8823 invoked from network); 24 Jul 2020 14:12:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Jul 2020 14:12:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B268C180509 for ; Fri, 24 Jul 2020 06:07:22 -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-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 06:07:22 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id e64so9683077iof.12 for ; Fri, 24 Jul 2020 06:07:22 -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=im9cQFP5VDfDfCYiJoz31cqa+IL0oTzHHBEqc8xc0xs=; b=P5wbrlzxQ3hV2VA64nvbouGDU9IXL5HCyJBlHq6zyN77kmbRi2hEKaool/QPBq0gdB h0yzMto8qG+VNrEsp6rBFg6tnX/aOjPzDWFrCmTG+TYOalqmw1ncEPWxDa175YWfXqlB rLUtIJMgm/BFvk1rpHswZ6pfy+1QBjb2mUZIckdaMp0lWxUaXke+Az3+zYr9LXnkyjfM HKNGYYEX/a32sTxi3oYii+YoZO8Q6z9F2sf6s+NpyKGkY8sRnQWapgFeFFD1hxXz4qk3 JlBA7x0gJ1Esf90FMvLq1aAVCKEUGtDv08q+AAyx27z3gu4fTAHIe4M3qVb3K1DWVD6u 5W6w== 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=im9cQFP5VDfDfCYiJoz31cqa+IL0oTzHHBEqc8xc0xs=; b=teQlZtuMg0DDVOzbG1RlgZvDqr0URto9RsxCpPj7edWCI1UV+QW5cDz02lCpkT5a+3 QLeQSLgu2Is5zCnWNX/WZrEyHCaDxS5qeKGRQ4f508tjELNaqQ2EGpzHQzZQ32hYsvx+ bb3PNIa/0rQtYgAtxImAaqArsP2nEOSGWMWKUKbFUBVR0xEWNw/1cs6jl/oi3IrI3Iam ZogEE3FCUsoNB2HrpfYLh3kyqpgi1mF2P4YkT74GCYIaJUmibJWXX9kryF14klznSApc GtRPp0t3uRIUBGV44xsKiBntinHwiPzAZ5xlNUK3iFS1hIB5Oii/xWNxUH5XZEaWH/jR giEA== X-Gm-Message-State: AOAM530loG2s2cb7Ufb9xXKl4SrPY9mMs+QbchRuh3qp0i7b43lBeB82 LV8Rm4bPa5eLUNQsraUc7PLS75qw X-Google-Smtp-Source: ABdhPJz9rjQrPA0v4OseE22ZJiRfFxBbmee3mvRpXv2AF8lpZyfuvTFrnYCBReB5/+xfunhqvrPn2A== X-Received: by 2002:a6b:6413:: with SMTP id t19mr10089480iog.167.1595596039609; Fri, 24 Jul 2020 06:07:19 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com. [209.85.166.41]) by smtp.gmail.com with ESMTPSA id k8sm3293844ilk.11.2020.07.24.06.07.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2020 06:07:18 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id q75so1542056iod.1 for ; Fri, 24 Jul 2020 06:07:17 -0700 (PDT) X-Received: by 2002:a02:9109:: with SMTP id a9mr10925569jag.130.1595596037619; Fri, 24 Jul 2020 06:07:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 24 Jul 2020 14:06:42 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Chris Riley Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000071abc05ab2fa730" Subject: Re: [PHP-DEV] [RFC][Proposal] Renamed parameters From: phpmailinglists@gmail.com (Peter Bowyer) --000000000000071abc05ab2fa730 Content-Type: text/plain; charset="UTF-8" As a general point, Python went through this almost 2 years ago. Their PEP is worth reading (I didn't see it mentioned before): https://www.python.org/dev/peps/pep-0570/ Peter On Fri, 24 Jul 2020 at 12:13, 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 > --000000000000071abc05ab2fa730--