Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128013 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 lists.php.net (Postfix) with ESMTPS id 52C091A00BC for ; Fri, 11 Jul 2025 13:30:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1752240508; bh=kLLI9VVqD7FL4nYxkqgXcvjNTryzzxDCjZ+wz4uUbsY=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=Mr8XAIgpLRS3hBs1OjT4v5ysMplxPnTrqqWZAlKHYsfhPOgoXzFqXXbhDTH8M6az+ kk3MQWl8QGCK5QTBGo8gSExYq5rCDw/e54J3r+zQpkh7WNNHay6r/AcD8jMrtBGQMC 0dfokArKnXDqpoFCuLZy998N76h5QSpUlA51M/eE7H1Ou+qf6LKkx79HEUwAk+IRlu mAO98VO8HjH+Tel8CNYuakhj1x/+8MmN8sQop+HahgCa13gu551JKDc7Mtkuonrc5U Yb1o99/IOlE0vBqJb/LkynEMm+LXZdriTMXoocgU+DiPhJlXJ3/pssCi6qZy+dMP3a XfrWHSYPBBQ8Q== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C31DB180053 for ; Fri, 11 Jul 2025 13:28:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 ; Fri, 11 Jul 2025 13:28:27 +0000 (UTC) Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-3a6d1369d4eso1263704f8f.2 for ; Fri, 11 Jul 2025 06:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752240616; x=1752845416; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=domlShkv8i/QN+/dEnS+LbAiATZ+nO7NmAyb/L8ry7g=; b=CoLiV5pKzpcxSWGdkRAZ3n8IL+pEuDkxYqOp7xpK83k2g88vI55o8V5LPD0mq47cLE hIabF8St3psXGkUIRyWiDdujVRSGispyIByRbmngLCdxeJlwy/N3vkuYl302tzBbwKV9 bE99tiPH0o5V+tTZH4meNdwYboaMyk0tftYUVCWP3dtgwHZzyQ4FtB+RTlrBHEmyEfoj wqBE3vI3/2p6EQaWd4UKkCBDGpuj/TyhnMR9TkalehYBNBQzXGug+ZOCPBMQe6WzjCh+ HzK8hbUwfLxvM+dx8hrvniqcDG2d4wOuWNwsz3WJPBI64zOywxg971mmF9FL+ZaSVsNm FC3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752240616; x=1752845416; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=domlShkv8i/QN+/dEnS+LbAiATZ+nO7NmAyb/L8ry7g=; b=CWYksdG3ttovYREEw6vB6FFyAp1GE541tXjiFD+YXjNtmL5bfpD2DXjrmjQkU3c93L biEebWfwNJwMczbZRTYPFbt60XdAL/CbYqhp5+8WbGkTXzDCYLMV4RrP3S4V6FpSfPOV kgJVd7yIIk1CIokHGvOpUA9mjWAL920xN3zHxILQaloM1Ulh1YV0oe1HXt7sco5j52pK uqO0Fvpp8XVfJiXygT7jagpsh5nLJhCJDX665qU/PKWZDL1ItbZFKMvSnKrU5d3r/gzL s6krJ9KqEpDmaTLHpN0exMr2Dz+nuCHqYpHjKBfrWIeL2Kot5ggcX8uE3U4FXEPmI047 3XLQ== X-Forwarded-Encrypted: i=1; AJvYcCWiZYbTL36Y/rgAv9ShQoSaKX8jjfVqHCa90X3V9EOm9p8/YGFget5h/mM4+bGBC7H8+jujTJ8elag=@lists.php.net X-Gm-Message-State: AOJu0YyLh3W9c9hRBUrc3CvHYsvEGLm/sF3GFw05COpQuplxbIXUvH7H G8F/uJVdvm1pfMO9wGWkWNuwF0/UquemsdGE+WIhafzN7D45kkRnmj1EEr/ifQ== X-Gm-Gg: ASbGnctDf05pocdP22COABWdm6g+iNwgUMcGf1S3fAFLX7oJnQWqWSrMPQgzLDUhWUC UeTWJVnzvn9LVNMy4/m5OWH3dLTPcGBALyszIWzIXT1cN9C49DTgI9/YX1+BdtFUEkMSeusX+gd lIq32bxEE4P0X5OZR2MXKUtnr6KrKLIUcFsxSgbojo0I5HxbC/4jOJ8eQpAma8LPxtPQcH7re4b zA7Xj815EUsWA+BPAG6iyPl9UZZGi0FM5/YpQ5ualEb6DQLKy3FusNa37ebc54kJ8ky/Z++VhVI vWzJkZKfPnga0jnPkZWBt4xwgCn5sjEBXJB2ArVp/nJwdiBws1zWiQpFk1pTd4JlxO824ywtCGF PfoHuD2Ogw3WD1+NP4IJ1w6E1FWRPohsutk/QSJPQB85SNQ== X-Google-Smtp-Source: AGHT+IF3o6S4MbThU5YwoF+dV5QZrEYmet5zu29sP9dvZQXELMU6EyTMqlu+NZ5frYWWja0ChCT8WQ== X-Received: by 2002:a5d:6f14:0:b0:3a3:67bb:8f3f with SMTP id ffacd0b85a97d-3b5f35955e2mr2176588f8f.53.1752240615354; Fri, 11 Jul 2025 06:30:15 -0700 (PDT) Received: from smtpclient.apple ([89.249.45.14]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b5e8bd18ffsm4392863f8f.9.2025.07.11.06.30.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jul 2025 06:30:14 -0700 (PDT) Message-ID: <197FA76C-8EF5-4BF4-A8A1-628180AC183D@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F7AF4942-6D42-4821-85DF-57EAB2D37185" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Subject: Re: [PHP-DEV] [RFC] Readonly property hooks Date: Fri, 11 Jul 2025 15:30:04 +0200 In-Reply-To: <203C1BD7-E688-4E26-8EA6-EA5331525470@nicksdot.dev> Cc: Larry Garfield , php internals To: Nick References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com> <9D5043B2-1589-4FD5-B289-6E98FB1177BE@nicksdot.dev> <16BD443D-A179-465D-84A0-6E3780F62D8E@gmail.com> <203C1BD7-E688-4E26-8EA6-EA5331525470@nicksdot.dev> X-Mailer: Apple Mail (2.3826.600.51.1.1) From: claude.pache@gmail.com (Claude Pache) --Apple-Mail=_F7AF4942-6D42-4821-85DF-57EAB2D37185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Le 11 juil. 2025 =C3=A0 11:38, Nick a =C3=A9crit : >=20 >=20 > I am afraid here I do have a strong opinion. Please remember my very = first mail before discussion [1]. > While for Larry the main reason for `readonly` hooks is = lazy-initialisation, for me it is to write less code, to have less noisy = classes.=20 > I don=E2=80=99t want to be forced to add readonly to each property. > Now you are proposing a mandatory `cached` modifier. Which means = *checks notes*, I would save 2 characters on each property. > You will understand that this is not in my interest, and not what I am = proposing here. >=20 > But aside from that I do not like to write more code. I honestly = don=E2=80=99t see the benefit of having this modifier in the first = place. > How =E2=80=9Calternative implementation 2=E2=80=9D works now is IMO = just good. And it makes sense because it is limited to the `readonly` = context.=20 > There is no technical need for the modifier. As we see, because we = have a working solution at hand. >=20 The reason I prefer an explicit `cached` modifier (as opposed to have it = implied by the fact that the property is readonly), is because it = changes the semantics in the following ways: * the get hook is bypassed in more situations than non-cached get hooks; * (depending on the exact implementation details), the result of the get = hook is used to populate the backing-store. (Alternatively, we *could* = leave the get hook populate it, and just check that the value it returns = matches the value on the backing-store. The latter check is mandatory, = but I think we could automatically initialise the backing-store if = needed.) By contrast, modifiers like `private` or `readonly` do not change the = semantics, but only add restrictions on when the relevant operation is = allowed. But this is just my opinion for making code more obvious (as opposed to = save few keystrokes). If other people agree that `cached` may be implied = by `readonly`, I won=E2=80=99t fight against that. > Can we please agree on that it is future scope whether or not non = `readonly` hooks should get such a modifier? Personally, I don=E2=80=99t have objection to relegate non-readonly = cached get hooks to future scope. =E2=80=94Claude= --Apple-Mail=_F7AF4942-6D42-4821-85DF-57EAB2D37185 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Le 11 juil. 2025 =C3=A0 11:38, Nick = <php@nicksdot.dev> a =C3=A9crit :


I am afraid here = I do have a strong opinion. Please remember my very first mail before = discussion [1].
While for Larry the main reason for `readonly` = hooks is lazy-initialisation, for me it is to write less code, to have = less noisy classes. 
I don=E2=80=99t want to be forced to add = readonly to each property.
Now you are proposing a mandatory `cached` = modifier. Which means *checks notes*, I would save 2 characters on each = property.
You will understand that this is not in my interest, and not what = I am proposing here.

But aside from that I do not like to write more = code. I honestly don=E2=80=99t see the benefit of having this modifier = in the first place.
How =E2=80=9Calternative implementation 2=E2=80=9D= works now is IMO just good. And it makes sense because it is limited to = the `readonly` context. 
There is no technical need for the modifier. As = we see, because we have a working solution at hand.


The reason I = prefer an explicit `cached` modifier (as opposed to have it implied by = the fact that the property is readonly), is because it changes the = semantics in the following ways:

* the get hook = is bypassed in more situations than non-cached get = hooks;

* (depending on the exact implementation = details), the result of the get hook is used to populate the = backing-store. (Alternatively, we *could* leave the get hook populate = it, and just check that the value it returns matches the value on the = backing-store. The latter check is mandatory, but I think we could = automatically initialise the backing-store if = needed.)

By contrast, modifiers like `private` = or `readonly` do not change the semantics, but only add restrictions on = when the relevant operation is allowed.

But = this is just my opinion for making code more obvious (as opposed to save = few keystrokes). If other people agree that `cached` may be implied by = `readonly`, I won=E2=80=99t fight against that.


Can we please = agree on that it is future scope whether or not non `readonly` hooks = should get such a = modifier?

Personally, I don=E2=80=99= t have objection to relegate non-readonly cached get hooks to future = scope.

=E2=80=94Claude
= --Apple-Mail=_F7AF4942-6D42-4821-85DF-57EAB2D37185--