Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112131 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 99171 invoked from network); 28 Oct 2020 15:38:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Oct 2020 15:38:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0AD3F1804C3 for ; Wed, 28 Oct 2020 07:57:44 -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=-0.6 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, 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-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 ; Wed, 28 Oct 2020 07:57:43 -0700 (PDT) Received: by mail-wr1-f42.google.com with SMTP id m13so1760955wrj.7 for ; Wed, 28 Oct 2020 07:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=qPpdqSvs8N9lx8aMx7Ix9FuptBmaMDUZBAft11wY1g0=; b=bznI2T23eo435hSbfVFq86DKer1UUQIZ+2zxs4SuF4XsJYX8dgaSxx0NBcLOZNMl21 jKIeleAUZs4QvK2X2f0v61gIrykHE9l1zDzDiujkdY5TmaMArzuc3d2AczV38k4Ub8Ka PqgZXdU/UnX5Sb7/15ZmWgQOObio2nmDBV6TPDStWqes9svwf2GD0+a38M/m+uonFsfz 8cNFcPPNkurnJm/UCsx9invxJckdu7kQzDyaxyCyCDUT32yILc36faDQ//qMYkiwNBE1 zfkfbzjJe4pAtnJeQ8ix0bgu7LWvIgN1weTxBmNQBfxpFJeCLKpqclFwco7qqDAh0InV 7iJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qPpdqSvs8N9lx8aMx7Ix9FuptBmaMDUZBAft11wY1g0=; b=kz2NKRo6fVvMNG4/cZpmwc8lkCmr+CcwQ0goCtiaXu9dYRtO3q17Ix6P2L9Kx4Aj2p Yc+HDshL2n1J+f15McdS+WucyNqgkB4MZC2Rh0mU195Ky9e8PP1QP/t+/odMwsZXzqhm bFZJ0yhLkqvWBEW8U6yYmcTAFqFEive6hVpnQVMAGw6yYT+rNkjXBs7TbmcJKyFct8c+ oe1PLXU5S6xyx9krTD7EfD7VNG5jBM/aWOka+uSlV7Gho0N4+Afs36533RKQ9Pf9VEpG IZOzSZGyRG3OZttLE06zLPw11AIxQrXfdZ88c2/P9kryvhDjdC3ELJpGfW0ti0y/LVvf WzkA== X-Gm-Message-State: AOAM5330xp3G3vjpOgIhmfMeFqncFQ4nME9pqyJzGtLm2CGpsx+Jy9Xl cu25YYcE3ll5y/x7HXo/8jMwClPU9wY= X-Google-Smtp-Source: ABdhPJzI9iRggqkLNh3fxCua98ZluHuHd76ypIN0wHqsVxv+MFp04hticVrOOlCTN6Bs9R7vFJoPzg== X-Received: by 2002:adf:e70a:: with SMTP id c10mr9169876wrm.425.1603897062091; Wed, 28 Oct 2020 07:57:42 -0700 (PDT) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id p9sm6587182wma.12.2020.10.28.07.57.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 07:57:41 -0700 (PDT) To: internals@lists.php.net References: <893315378549048c16f2dc212bdec698fe32f8d10d37f9c5f74ffd179a1e0de9@mahalux.com> Message-ID: <73716a39-53ac-c9b4-a38a-86922a2edeb2@gmail.com> Date: Wed, 28 Oct 2020 14:57:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <893315378549048c16f2dc212bdec698fe32f8d10d37f9c5f74ffd179a1e0de9@mahalux.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does not throw From: rowan.collins@gmail.com (Rowan Tommins) On 28/10/2020 10:45, Michael Voříšek - ČVUT FEL wrote: > https://3v4l.org/X8omS parameters renamed, result with named parameters > is different While it's easy to construct an example where this happens, it's harder to imagine a scenario in real life where: * a sub-class overloads the function with different parameter names... * ...that overlap with the original parameter names... (i.e. the call will succeed) * ... but not in the same order... * ...where calling with ordered parameters results in the expected behaviour (i.e. it's not already incorrect code) It seems more likely in practice that a polymorphic call assuming the parameters are in the same order would fail where one assuming they have the same names will succeed, e.g.: class A {      public function search(string $needle, string $haystack) { ... } } class B extends A {      public function search(string $haystack, string $needle) { ... } } $aOrB->search("foo", "foobar"); // incorrect call on instances of B, but allowed in every version of PHP $aOrB->search(needle: "foo", haystack: "foobar"); // correct behaviour whether instance of A or B :) > https://3v4l.org/kgHWf renamed parameter, call with named parameters > does not succeed at all (which violated basic principe of OOP > inheritance at least) This is the case that is explicitly discussed in the RFC: https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance I'm not sure what more can be said than appears in that summary, and in the linked discussion of rejected alternatives. As the RFC says, the pragmatic decision was taken to defer these errors to runtime. It's worth noting that since PHP doesn't have checked exceptions, a child method throwing an error that it's parent wouldn't is already possible and not considered a violation: https://3v4l.org/3m7eo Regards, -- Rowan Tommins (né Collins) [IMSoP]