Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118556 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39000 invoked from network); 2 Sep 2022 19:32:49 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Sep 2022 19:32:49 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0ED091804D0 for ; Fri, 2 Sep 2022 12:32:49 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FREEMAIL_REPLY, 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-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (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 ; Fri, 2 Sep 2022 12:32:48 -0700 (PDT) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-33dba2693d0so25277587b3.12 for ; Fri, 02 Sep 2022 12:32:48 -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=g6oey9C/tRI+iPRiO/Pz8oVRGXN0Gx6D3Eoy9gdzMis=; b=Y8FWOkfOMWDkKKs8TOxuJIRiTS3guJZu81UfvRNVNxopiiBHmv0qNOI1R/6qsTat16 8sy64ZLyQQ8XIge/hc6yHLczAIAgpk9Ccz8Iwcn0PvPHlxQZ5J/wGYC1+inJVUkLzTLo 5PsNKEX+vmIvmM9K4RV2eF+jwrdoQ8vbcdEoSUmi0Ri4ZbudULXTCmycCNt/YqTY6wJp lMuziiHSkXSAQzrWZ5BS7rZ6Z+AccEqwHwQEIb26veru4r7nbI0xeNCLB+1vQtMLNcaQ 6x6HuBiGh+3kgw/YhRcYJWxGcREFunMKsUwjeKCZv1NQKjfG0R+I1XgPM3lfH5UTa0d0 EyIQ== 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=g6oey9C/tRI+iPRiO/Pz8oVRGXN0Gx6D3Eoy9gdzMis=; b=dvbDDrM1CjqwcuZczv4VluSP4O2c/6mxwPCrxOWDyjQYFHYv4ZcBJWheplkvZ/U35P JvAKUy+En4k0OlBVmOzrl2/kWhBOUHWkcLzAs5r2jM0YwOw825hZV+8IIVWooAVSgRZZ bQrlx/sxQuZmHzOBJRRzuifKmBVVu8sF5wUqetnPq5f9DL09/f7NdKlhSw4J6k8p9/mN NyRaVxQUev2ly6vSA69IyblkIvvGWk6mfAYrCa58VWQmlocraK9EktJC/sAcCiS5rJo2 CKnJQR3o89bQANaDzDvpHjYJq30j8gaq59veeevN5rbxh58Bv3bVj4KX3D8s3jn4Zzc4 I0Ow== X-Gm-Message-State: ACgBeo1QGxB1wFATgGbf335YuwmOjOEPzbN2IWZ9cj4jZu1RdYR0xWyY eON4yChhSLlb9IDqXlcOk0Fui0gw8YQVFTrgOmw= X-Google-Smtp-Source: AA6agR5HU2gZe/5DsRbs+ecyBfH8tK/zPA0xyySPRIf6mvUzTLPXrMt6tQyLUOb2T4lnEqCx7YRpMACylRINRvaDprA= X-Received: by 2002:a81:c89:0:b0:33d:c240:a9ac with SMTP id 131-20020a810c89000000b0033dc240a9acmr30527338ywm.453.1662147167859; Fri, 02 Sep 2022 12:32:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 2 Sep 2022 21:32:35 +0200 Message-ID: To: Nicolas Grekas Cc: PHP Internals List , =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= Content-Type: multipart/alternative; boundary="00000000000081390b05e7b6cba9" Subject: Re: [PHP-DEV] Issues with readonly classes From: ocramius@gmail.com (Marco Pivetta) --00000000000081390b05e7b6cba9 Content-Type: text/plain; charset="UTF-8" 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. Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/ On Fri, 2 Sept 2022 at 19:31, Nicolas Grekas wrote: > Hello everybody, hi Mate > > I played with readonly classes recently, to add support for them to > lazy-loading proxy generation and I struggled upon what I see as serious > issues. > > As noted in the RFC, and because the readonly flag must be set on child > classes, those cannot: > > 1. Declare a new non-readonly property; > 2. Have static properties; > 3. Have dynamic properties. > > I figured out 1. and 2. not by reading the RFC but because I needed those > capabilities in the generated inheritance proxies. > > 1. is the most serious one: being able to declare a non-readonly property > is the only way to implement a cloneable proxy (to be allowed to do > $this->realInstance = clone $this->realInstance; in __clone()). I think > there are two ways to solve the use case I have: A. fix the > non-cloneability of readonly props or B. allow child classes to add > non-readonly properties. Because to me this is a serious restriction, A or > B should ideally be in 8.2. I think A is a must-have so that might be the > thing to do. But I'm also wondering about B: the RFC doesn't contain any > rationale about why this restriction exists (it says "Similarly how > overriding of readonly properties works", but the similarity is quite weak, > readonly props don't apply to other properties of child classes.) If there > is no compelling reason to have this limitation, it should be removed IMHO. > Basically, this would mean that child classes of readonly classes wouldn't > have to be readonly themselves (but the existing properties on the parent > would have to be of course.) > > For 2.: static properties are useful e.g. to cache some shared state (info > extracted from reflection in my case) and I really don't see why readonly > classes should forbid static properties. Readonly is only useful for > instances, because it gives them immutability, but what's the link with > static properties? Note that this is less important than the previous point > as it's always possible to store shared global state in another class. But > still, this feels arbitrary to me. > > For 3. I just noted the limitation to be exhaustive, but I'm really fine if > dynamic properties remain forbidden on child classes. It might be seen as > inconsistent with other classes, but dynamic properties don't have any > purpose anyway since there is always an alternative to them. > > I understand there are good intentions behind these limitations (making PHP > a stricter language). But here, I feel like this is detrimental to the > language, by making it a minefield of kinda arbitrary dos and don'ts. At > least that's what I feel here. > > Does that make sense to you? Should we remove the limitations I mention? > > Nicolas > PS: About allowing readonly props to be reinitialized during cloning, I > tried https://github.com/php/php-src/pull/9403 but I failed as I can't > make > it work. I'd appreciate any help on the topic. I'd even be happy to close > if someone else would like to work on the topic. Could that be you? > --00000000000081390b05e7b6cba9--