Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123561 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 774061A009C for ; Sat, 8 Jun 2024 14:27:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1717856930; bh=PbUK/Vr2MRZXZJMjXZ2tT1W7BvURuDpjHMsQjn3nwgE=; h=In-Reply-To:References:Date:From:To:Subject:From; b=a6uK9SKtf55D43N8yAmc6il35ZLKoi5/BZqfmLk8fyXdBRCW6I+bEpWV86qVaf9GT cT7giKyRHazaLxfsyBteeQn4vNKUfbXSLanigNGRUfXSJ+IVu91GI42z5sPpHMKHqe ARitt0LOeCMQ0+kOFKo2WCy1oT/njZxcpyRDdNgJc7a/2qngRrBnJBdliPfYva0IuM BRGbwfnEFpIr/yxFjsqDEFDWTzJViU9ad305F7rDoVoi8j9fd1raZ/4FmItyKJSSiI cP5t01aQztTVWJzNG8O+d+ZAWgT6rq0b/SU/+61xC15W6PiHY0OcJF99N0IEbH6mTp mk8XuxPS0slig== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4D2F4180003 for ; Sat, 8 Jun 2024 14:28:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fhigh4-smtp.messagingengine.com (fhigh4-smtp.messagingengine.com [103.168.172.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 8 Jun 2024 14:28:48 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id E0F0E11400CF for ; Sat, 8 Jun 2024 10:27:41 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute1.internal (MEProxy); Sat, 08 Jun 2024 10:27:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-type:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1717856861; x= 1717943261; bh=rLz51n6KsA2VUBTJR+r6nJZeqvkdnA6dZZyjQgKj3WU=; b=U ZpToBYF6oUZQvILAAJQL/1vcNgDzSK5i5fJhh8YSzLX34icdhMCzC2F0ktPR26Am UHHN3CjSIPJxykItGPUApw6ods6QqV1V03YN1+NetHBbtjYLA1+oxkOQ9hMH7bfE sCA+oUaX+wgeFp8vo5PfntLWM3hOEr3i46FXSkX2ihPJyIPxQSWZUzFcmGgH/0Cf gr2ot1SGFFQuKW7Xju32FvhkOp2v2q1w/cEnEaNjkC1CzgahU/c1BnoLV8G3OIeZ +KHxHmGezOgdiZ7u/LZJT+w6YQExfaW0wiTkE5y70JhbqGhU4Ic+jB6jDGkrqlpA H6CenEm54a2SshLtOiLXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1717856861; x=1717943261; bh=rLz51n6KsA2VUBTJR+r6nJZeqvkd nA6dZZyjQgKj3WU=; b=ggIYGPPeDxWHE70Xd7LQajZ5VCde5xo3xYmD3nmFGoyr tGyMnWvxMOhKZTM6DHUdsRw2lhQDP2uCQ0otNkjMYRWndc8Xtj1P4woWDQXFkKTr mV6bE5vfPBNEv2T/oWfV4Z8rCTAYysqOLgcK0bO0rcE2/xEhJXoCvlxxw48Rezh5 51yKRvqtNq+5QxfzaDTt0/JCNvy66jzBa9LEjdXlmAz3CbE2D9sWGlmV2hjB0yHa JrBR4kKaii23x9GIwDu0AIKoPf2gXG7Uj7Ts/F4Eb8xblssN9GNFcv4e0mTrXEdD TiTxw9En5MUro+wi2D2iEW/0KlHD5ji7BWhTOnUZYg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedtgedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeeglefgkeduiedvvdetffeujefftdfhjeeiveehgfff keduveektddvledvvdfffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 64DCD1700093; Sat, 8 Jun 2024 10:27:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-497-g97f96844c-fm-20240526.001-g97f96844 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: In-Reply-To: References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com> <734bb8e8-2fdf-4e50-9039-e53c99ee4930@app.fastmail.com> <89b695d7-661f-4c1b-ac4c-4480ad158e83@app.fastmail.com> <6d644f0f-cbeb-484c-b267-bf1d97e6d27a@app.fastmail.com> <10AAAA51-9538-4F97-83D1-91F154C745F7@gmail.com> <0b6d7308-3c32-477c-8bf2-e8e0880cbb05@app.fastmail.com> Date: Sat, 08 Jun 2024 09:26:37 -0500 To: "php internals" Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2 Content-Type: text/plain From: larry@garfieldtech.com ("Larry Garfield") On Sat, Jun 8, 2024, at 3:49 AM, Arvids Godjuks wrote: > On Fri, 7 Jun 2024 at 17:30, Larry Garfield wrote: >> On Wed, Jun 5, 2024, at 7:55 PM, Arvids Godjuks wrote: >> > On Wed, 5 Jun 2024 at 19:59, Claude Pache wrote: >> > *snip* >> > Hello everyone, >> > I've been seeing readonly bashed/blamed/being roadblock, etc, etc as in >> > the implementation ended up being sloppy and blocking other things or >> > making things hard... >> > While I know BC is king and stuff, why not just say "yes, this was >> > designed badly and we will redo it" and just do it? While there's not >> > yet an absolute boatload of that code out there when it would be >> > absolutely massive BC break? Don't repeat the mistakes of the old days >> > :D >> >> Well, readonly has been out for 3 years. There is an absolute boatload of code out there that we do not want to break. :-) >> >> > Cause the impression I'm getting any significant RFC now has to work >> > around the readonly's sloppy implementation and there's a bigger and >> > bigger section on that with each next RFC when there's more and more >> > advanced features for the OOP part of things. >> >> It's not a sloppy implementation per se. (I can't actually speak to the implementation myself.) It's the design of an implicit private(set) that works differently from any other private variable. The issue with "thou shalt not touch it outside of the constructor" isn't a language bug, it's a static-analyzer bug that those projects refuse to fix. Not something we can really do much about here. Uninitialized wasn't introduced by readonly but by property types in 7.4; readonly just inherited it. For hooks, the issue is that readonly needs a value to check to see if it's uninitialized, and with hooks, you don't always have that. >> >> I think at this point, the change discussed above (making it implicit protected(set)) is the best we could do. In an ideal world, we would have never added readonly in the first place and just added aviz back in 8.1, which would cover nearly all the same use cases with fewer edge cases and oddities. Sadly, the world is not ideal. >> >> --Larry Garfield > > It does depend on what the fix is - if we are talking removing readonly > keyword - that's a yikes and if we go that route, it needs to have an > official rector migration thing and it better be officially endorsed > and provided :) > If we are talking about tweaking how readonly works in some cases - > while not great, I hold the opinion that it's better to fix it now than > 20 years down the line. > > I do have to say that I do not see a "==" between aviz and readonly. > While I can see how you can implement readonly with aviz, the > boilerplate seems not worth it, especially for bigger > classes/structures where you just designate the whole class with one > "readonly class MyClass { ... }". And constructor promotion with > "private readonly Class $class" with DI is basically all my services > now - it's convenient and short and I really do not need any more than > that from the readonly :) Maybe simplifying readonly is the answer and > use aviz for more complicated cases? That is essentially what we've ended up on. For *services*, aviz is probably not super useful; for that matter readonly is only marginally useful in services, but a lot of people (myself included) use it as a matter of course anyway. The only change we're discussing there is that "public readonly" or "protected readonly" will now be implicitly "protected(set)" instead of implicitly "private(set)". If you're already using "private readonly", then that will actually get a bit stricter as it removes the loophole that exists only for readonly. So this is a very small, focused change. Aviz is much more useful for data classes: value objects, DTOs, domain models, ORM models, and so on. For that, readonly serves one narrow use case and does it well, but falls apart and often gets in the way for anything even slightly more complex/interesting. For that, aviz offers vastly more flexibility and robustness in about the same amount of syntax. --Larry Garfield