Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120391 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3774 invoked from network); 23 May 2023 15:47:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 May 2023 15:47:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 93564180538 for ; Tue, 23 May 2023 08:47: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=1.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_SOFTFAIL, T_SCC_BODY_TEXT_LINE 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-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 23 May 2023 08:47:56 -0700 (PDT) Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-3f38a7c5d45so22753161cf.0 for ; Tue, 23 May 2023 08:47:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684856875; x=1687448875; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MtcYZZUXFmQO/8f8hjgUE7xij6jQxmw4rmM5r/I2B+o=; b=E1Z1yIykcSzS9f730BvHpE3W92jyQxG1pgbFWHydBr1zCGkoEAOri0u//EoBUO2The BGWw8mA4jKQs226XZ0JGBDgCSidUi2B1Gf02+cwCUo0RBP4gsL993sqeGial//vcylk8 yG4r5uYu/3Brlrp695aXVdyDcjxgagpvJiPqBXhAugYmM+kj+K5GeVVuTAC+Wft63ZAc 4W+tzFDZIe/C7tbrO7dpj71V5S6CTG1BsygX88q+k4hkfWRcrRfNzd32c0BDQvR8xrSS kAfaYSDhYsAaTWMhQ030ekF9ETMEyrzKShFJdRD9kbrWt0l69Rqnd1/SPzKlrSXsGCPk U8zg== X-Gm-Message-State: AC+VfDzh//CDigKZqQ+rVav0ZF1dBTNOXw3nYdcjb7C4LVgBLJe3QsVg Z1OhjlyclSjZ6otcW45jR6NdhpdSXXBTyXjgiTOIy42otBORkox4fO4= X-Google-Smtp-Source: ACHHUZ6d7F5c1WeT5L5QIJTRCxSVvaqz1MZRbT5N5pBaVZIBxpdRog0okKoDqrLtVyP6ZL9uM+mzsJdxFF5aRXGZfoo= X-Received: by 2002:ac8:5c84:0:b0:3f6:afe7:18d1 with SMTP id r4-20020ac85c84000000b003f6afe718d1mr9812198qta.34.1684856875419; Tue, 23 May 2023 08:47:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 23 May 2023 10:47:44 -0500 Message-ID: To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000008ead7805fc5e4f05" Subject: Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override]) From: pollita@php.net (Sara Golemon) --0000000000008ead7805fc5e4f05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 11, 2023 at 11:37=E2=80=AFAM Tim D=C3=BCsterhus wrote: > > I'm now opening discussion for the RFC "Marking overridden methods > (#[\Override])": > I 100% get the intent behind this RFC, and as someone who's used this in multiple other languages the benefit to defensive coding is obvious. Thoughts: I think targeting 8.3 is aggressive as we're less than a month from FF (accounting for discussion and voting period). The first argument (about not impacting callers) for "why an attribute and not a keyword" feels like it's tying itself into a knot to make a specious point. The second argument about FC is more defensible, though I personally think it's not merited in this particular case. I'd personally rather have a keyword here. If you do go with an Attribute, then I'd go ahead and go further by allowing to specify the name of the class being overridden and possibly flags about intentional LSP violations. For examples: // Intentional LSP violations class A { public function foo(): \SimpleXMLElement { return simplexml_load_file("/tmp/file.xml"); } } class TestA extends A { #[\Override(Override::IGNORE_RETURN_TYPE_VIOLATION)] public function foo(): TestProxyClass { return TestProxy(parent::foo()); = } } LSP checks are super valuable for writing clean and well debuggable code, but sometimes they get in the way of mocking or some other non-production activity. This could provide a "get out of jail free card" for those circumstances where you just want to tell the engine, "Shut up, I know what I'm doing". // Specific parent override class A { public function foo() { return 1; } } class B extends A { // Not present in older versions of library, just added by maintainers. public function foo() { return bar(); } } class C extends B { // Errors because we're now overriding B::foo(), not A::foo(). #[\Override(A::class)] public function foo() { return parent::foo() + 1; } } C was written at a time before B::foo() was implemented and makes assumptions about its behavior. Then B adds their of foo() which breaks those assumptions. C gets to know about this more quickly because the upgrade breaks those assumptions. C should only use this subfeature in places where the inheritance hierarchy matters (such as intentional LSP violations). Just my initial thoughts, overall +1 on your proposal. -Sara --0000000000008ead7805fc5e4f05--