Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119039 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 37576 invoked from network); 26 Nov 2022 23:40:26 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Nov 2022 23:40:26 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1B1621804A9 for ; Sat, 26 Nov 2022 15:40:25 -0800 (PST) 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, 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-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 ; Sat, 26 Nov 2022 15:40:24 -0800 (PST) Received: by mail-vs1-f41.google.com with SMTP id k67so7371462vsk.2 for ; Sat, 26 Nov 2022 15:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kAsc+GL5pgs5fnGLUwjSAnUKCs311jq1rLK3cEsUqts=; b=LH02xGHzzzNJDQ2/SdvVXmbVYjClUrIZOFZBIZEnTpyUqhZUjGMRPFo/nGga4T3SSe +LUcPrthQ7xCy1e63k7jBv1kOTMdDZmf4ng9tM5zw4EosFBLq3ek4kztsceWQ/Zf36ga 7E5/e5iLJT2nSuprJGzTezId49Vn/8qNNGUTW0tkH64hGMKeHjxRKz73uGNaj4xpi7LJ TjXcTRXcJko1QiQ2wsoWdeWy4RhTExZI2RRs7iY11pjmIiLVfWqpL2AA6jZ+FcvEIJ6v YpEYXVGoeOhjAY9ZiSeH4KctLI72iE9D2Yr0tHXQqLK8DHqBmgDU+CB/N0Sm0WNEioCZ j8SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=kAsc+GL5pgs5fnGLUwjSAnUKCs311jq1rLK3cEsUqts=; b=vog0075JDH8s7bbrta2d96qSMC1dlGTFzhhuyLZn7NDyQKIGzdclu2nl2r+/+WddEC Gt+uhDTWIdnl8dKzJ9ffzyqm9yRSyFEHkpVaWVqYP1NRfP2bUmoVkP3rGbAyUKBfP0nJ h6SVNmgZ44UGcQjvkcT67CcTB+497np50GfJHdLEoOUpRh3Omu1P5s4y/HCA55W3FSAP E8B1Fxw2r/r6RMWkIukhRIHs3XygYMAIuiTAE0dRxdHkk/UCkxg1VxvU7wLB3KN0uTjr uHZ8YS3iZmqvwcfSPuBwwnLIDQUCJJi1NspdyKEAGJBtvKY75wQVfXvqFWRE61amhkoe eW3A== X-Gm-Message-State: ANoB5pnpXt4bHibGG+dM03F+zA9hwABv3iSFndbIOAmrlHj3pWT+o/Qy tARYo4j2Ef+a2z2rfzlSMmNYtsVHGldVVmgX6sQZMzGY X-Google-Smtp-Source: AA0mqf6QNzSE0fgQ88HClBC84KwWbRFH3VkwMZNkUKVfaF0idB/rCxwmjDIUOzFnv+ockH/HwWDjHbe8gvLyLhZTGVA= X-Received: by 2002:a67:e219:0:b0:3b0:87ba:a178 with SMTP id g25-20020a67e219000000b003b087baa178mr4926374vsa.55.1669506023853; Sat, 26 Nov 2022 15:40:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 26 Nov 2022 20:39:47 -0300 Message-ID: To: Marco Pivetta Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= , PHP Internals List Content-Type: multipart/alternative; boundary="00000000000080969605ee682989" Subject: Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments From: deleugyn@gmail.com (Deleu) --00000000000080969605ee682989 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 17, 2022 at 11:47 AM Marco Pivetta wrote: > ```php > > /* readonly */ class ImmutableCounter { > public function __construct(private readonly int $count) {} > public function add1(): self { return new self($this->count + 1); } > public function value(): int { return $this->count; } > } > > // assuming the proposed RFC is in place, this is now possible: > class MutableCounter extends ImmutableCounter { > public function __construct(private int $count) {} > public function add1(): self { return new self(++$this->count); } > public function value(): int { return $this->count; } > } > > $counter1 = new ImmutableCounter(0); > $counter2 = $counter1->add1(); > $counter3 = $counter2->add1(); > > var_dump([$counter1->value(), $counter2->value(), $counter3->value()]); > > $mutableCounter1 = new MutableCounter(0); > $mutableCounter2 = $mutableCounter1->add1(); > $mutableCounter3 = $mutableCounter2->add1(); > > var_dump([$mutableCounter1->value(), $mutableCounter2->value(), > $mutableCounter3->value()]); > ``` > > ( https://3v4l.org/IDhRY ) > > That's really really confusing, buggy, and, from a consumer PoV, broken > (LSP violation too, transitively). > As I think more about this, there's nothing about the current RFC in this code sample. What's breaking LSP here is the child class doing state modification, not PHP. To further expand that rationale, PHP allows us to create child classes. Whether that class will be LSP-safe or not is up to us, not up to PHP. However, the point still stands. Allowing child classes to break readonly will make it easier to build code that breaks LSP. The question then becomes: why is this being proposed and is it worth it? As I read through the RFC, the only reason this is being proposed is because "it breaks decoration via inheritance". Doesn't `final` cause the same issue? How is this problem being handled if the class is marked as final? If you can't extend a final class to build your "decoration via inheritance", why can't the same argument be applied to readonly classes? -- Marco Deleu --00000000000080969605ee682989--