Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110817 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11878 invoked from network); 2 Jul 2020 13:05:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Jul 2020 13:05:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7EABC1804DE for ; Thu, 2 Jul 2020 04:55:19 -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-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (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 ; Thu, 2 Jul 2020 04:55:19 -0700 (PDT) Received: by mail-lj1-f172.google.com with SMTP id s9so31540776ljm.11 for ; Thu, 02 Jul 2020 04:55:18 -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=77Rv8w+X2Lvtmhf6cOfhUD3zicHng70gXHpDQTqO3ac=; b=lwW8Vq2VH1uQIPIfJs2Ku13GlYlPrgYa4eEkT4BmTPP9zCzGEBzfULIo7VIBGr23Ul 2AA4aRrN/4xQMVQTrtRXvVWriWxt3DwKkleYvIlEijzMzsIbNLCduGdMefstW4tfxJVU V+fhDpeStm1VeONKU6Nf57UVkdj8YN4DitIocuymIP3y5Gh+44UCNlSyln8pxXLjPBwH BHeg6EhQwmKej5Jy/6xza+UuQelhaC7HYSIa8ddmOiiVt9Nfarfwmy25XqOLE7s5Vful QWnRAAnetHzkYSZVu4vxUHs91DMaE3GKl475Tpjv3BVIDVlA08VETCVO3UbRF7UXypHC sXWg== 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=77Rv8w+X2Lvtmhf6cOfhUD3zicHng70gXHpDQTqO3ac=; b=sUHPZ/59DbQ2fyDT/3qELDfpW2hI+eNaOkLQ8s2xGoMwHLlkCdpHyD7GVowgsuf2C7 HIU0H1/5jpypQ4kazfGRJTRXhtNZq8wA5EP7MSIxmAjkLXA7ZKJQe/RavYUNIJ7NZ2wA MFEk9H80TXGxj/uFutcju/yw+y0AYtEANhs8K08UdHbNpFukEpGlIA/wqzdmnafhfsiE vPa19MGuIY2+tIDxbK5Qld/NSRJ5uWNH8KyDSID2x032pU+faUsj1vw9PuPD2521fG+C HmzDSV/z120FMzJ/J3WQkXYzc9g6KDcyMhNhrhzZ2gzpQo5UNwrbxS0XgFh/o0BSEz2a Xf7A== X-Gm-Message-State: AOAM531glCmpy25r/iIT4r34bxk9rY5P1lF4nLhQfolnYwcZ8sAw3ct5 GIsvaC2erwqKCjdMK3xMWoCe1pI1tGAncMFI948= X-Google-Smtp-Source: ABdhPJyXIzY4yORIOCc8dfUBrV8pxCxAX3n0BBIt/8GzIoHtjHEFT2fxrNr4qU2gEHYl8kM93wiYb7imYZMVFBolrnw= X-Received: by 2002:a2e:b55c:: with SMTP id a28mr11855199ljn.42.1593690917521; Thu, 02 Jul 2020 04:55:17 -0700 (PDT) MIME-Version: 1.0 References: <5efdc304.1c69fb81.81fbf.90fcSMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: <5efdc304.1c69fb81.81fbf.90fcSMTPIN_ADDED_MISSING@mx.google.com> Date: Thu, 2 Jul 2020 13:55:01 +0200 Message-ID: To: Andrea Faulds Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000054d9b05a97415c5" Subject: Re: [PHP-DEV] Re: [RFC] Named arguments From: nikita.ppv@gmail.com (Nikita Popov) --000000000000054d9b05a97415c5 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 2, 2020 at 1:20 PM Andrea Faulds wrote: > Hi, > > Nikita Popov wrote: > > > > Regarding the question of what to do with regard to LSP validation and > > parameter names changing during inheritance: During internal discussion, > > the following option has come up as a possible compromise: > > > > 1. When calling a method, also allow using parameter names from the > parent > > class/interface. > > 2. During inheritance, enforce that the same parameter name is not used > at > > different positions. > > > > This ensures that renaming parameter names during inheritance does not > > break code relying on parameter names of the parent method. At the same > > time, it prohibits genuine LSP violations, where a parameter has been > moved > > to a different position. > > > > I've run some static analysis to detect cases that would be affected by > the > > latter check, with these results: > > https://gist.github.com/nikic/6cc9891381a83b8dca5ebdaef1068f4d The first > > signature is the child method, and the second the parent method. I did > not > > put in the effort to make this completely precise, so there's both false > > positives and false negatives here. But it should be enough for a general > > impression. And the general impression is that these are indeed > legitimate > > LSP violations. > > > > This approach would be an alternative to either silently ignoring the > issue > > (as the RFC proposed), or to warning for all parameter renames. > > Would this do anything surprising when variadics are involved? > The behavior of variadics is described in https://wiki.php.net/rfc/named_params#allow_using_parameter_names_from_parent_methods. The behavior there described there might be surprising. It's certainly one of the ways in which this approach is less straightforward than it initially appears. Regards, Nikita --000000000000054d9b05a97415c5--