Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118562 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 30926 invoked from network); 5 Sep 2022 08:17:03 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Sep 2022 08:17:03 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C4328180504 for ; Mon, 5 Sep 2022 01:17:02 -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, 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-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.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 ; Mon, 5 Sep 2022 01:17:02 -0700 (PDT) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-3452214cec6so21425327b3.1 for ; Mon, 05 Sep 2022 01:17:02 -0700 (PDT) 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; bh=8/05QyKfwcEB6vwLlGP8H6R3UaS5eovN5f9df/UehQo=; b=pJ95K3kjBqIlkwPuRnQ3cJP7yjTa0Ys1v15jcWnVHk9mOfPWn3HCcPBWGIjgTVycpt zXg5lZtBIHzfVx146Pqbg9DVnL0Dgm+14N/oL5ozglYm8WbzU9gWxk5sIZoHzAjTVHgT gP7s/gc+3/4MurUdX+vCOrAmReYD+fRm/rx59fO+5Ywr2u+CJsrAra9fiKgg4frSfHOv RI2SaJHsCMHbg83hRKEbBUb0sdzW/PMHrTFr/ExJWizLgXy4vfGYLw8KD9sE3dJ19Ge2 BxUbHQWtvCK9bF9DTQPpmLb09RgYTEy056smvmRcDII7B4OxIMJ2XETiS3YqVGD4bOJR Eb8g== 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; bh=8/05QyKfwcEB6vwLlGP8H6R3UaS5eovN5f9df/UehQo=; b=VggAfqBw5eemb6VtbSM/h/TIufPIy616DTvkfr0ZxslYH5AdaltEd48MzkkzlM2AY1 wXIX8E7hhyHbKG4ES0zFLHKC+Ow2SZIg4p1pYkOfDlUT6nx2TFMmJFZ7mKPJVDYLm+9b voFYi7xmj7pc8/RRmmUrLhw7MgM7bJO2wnh59R/5taMI4VXHkRBjaqfrGLW8TC3Qu1b0 EZPOqxvDhx60GmGKNqpqQG7GzWJcxxiHxrGs0ivfc9xW41FHUFFe/gX0ik95W4k+2W5O H4sM8l+4S6oHErWsM9LVjVPhG4DsDWK8xo0ysyxwEH1DlMsLx3fsTfoah766oDEtbUjv ukDQ== X-Gm-Message-State: ACgBeo0CtmS3dtMgWLhZbUsrrHfIOsxW6dje1niN1YD+XbxCspcdyZ16 YhOjuPYxCHaC8C9MleztNxT+AC9q6ET3Fbh9tvY= X-Google-Smtp-Source: AA6agR5Ng+kqskGpZ1jA5uInahkb9wmcrb718/S8L5ojuVuMQdHvJOkCwYeftqM8yoxQRMyzGaUp93Bud5Vn6ekbeC0= X-Received: by 2002:a81:744:0:b0:345:43d7:f097 with SMTP id 65-20020a810744000000b0034543d7f097mr2537200ywh.233.1662365821771; Mon, 05 Sep 2022 01:17:01 -0700 (PDT) MIME-Version: 1.0 References: <74826B75-7648-432B-9E04-D9A44252C0C4@php.net> In-Reply-To: Date: Mon, 5 Sep 2022 10:16:50 +0200 Message-ID: To: Nicolas Grekas Cc: Derick Rethans , internals , Marco Pivetta , =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] Issues with readonly classes From: landers.robert@gmail.com (Robert Landers) On Mon, Sep 5, 2022 at 9:57 AM Nicolas Grekas wrote: > > >Hi Marco, > > > > > >IMO good as-is: can be relaxed later (8.3 or later), if anybody believes > > >> it's a show-stopper. > > >> > > >Readonly classes don't really need to be lazy. > > >> > > > > > >"Break things and move slow" doesn't feel right to me for the language. > > > > It's a new keyword that you have to opt into. So it's not breaking > > anything. It just means you might not be able to use it for your use case > > yet. > > > > (and before you say that third party code might add it, you can just say > > you don't support it yet). > > > > It's not like it wouldn't be supported *yet*. It won't be supported *by > design of the language*. > > Readonly classes introduce a new concept that isn't backed by any language > theory I've read about. > Of course it doesn't break until you use it, but conceptually, it breaks a > universal design pattern: inheritance-based proxy decorators. > What I'm asking for is: what is the justification for this limitation? If > there is none, we should drop it. Preemptively breaking universal concepts > (decoration) by introducing a never-seen concept might be innovation for > sure. Or it might be a mistake. E.g. do we know any other language that > provides something like readonly classes? How do they deal with inheritance? > Can anyone answer those questions? > > If we come to the conclusion that there is no backing theory to support > propagating the readonly flag to child classes, then we might decide if we > want to fix this in 8.2 or 8.3. I know I would prefer acting in 8.2, but > that's a separate discussion. > > Nicolas > do we know any other language that provides something like readonly classes? How do they deal with inheritance? C# has readonly structs, but inheritance isn't allowed with structs so they slightly side-step this problem. (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/struct#readonly-struct) They also have "records" which are immutable class-like objects with language support for cloning using `with().` https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/record ... these "records" can inherit from each other, but a regular class cannot inherit from a record and vice-versa. Robert Landers Software Engineer Utrecht NL