Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128146
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 20 Jul 2025 14:00:03 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <ecc09a60-173c-46a7-b831-3ef62a0f26f0@app.fastmail.com>
In-Reply-To: <ba592eb4-5f93-462f-a7bd-84836e53d3c6@gmail.com>
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <CAMzRQTdDNsF_LPpNKUbVROTWjDbN2uDw-j2PrL3xp7qASA62GA@mail.gmail.com>
 <be533915-2b0d-460d-a5ea-76fe98fc4080@app.fastmail.com>
 <f4e4057b19a5ed9de7ad92215e78d58c@bastelstu.be>
 <cedce076-82de-4391-8a03-409690added9@app.fastmail.com>
 <bf4cc2d56f491606d3a3037af1243699@bastelstu.be>
 <13B58381-AA61-4D38-A688-DD9E367ADE6F@nicksdot.dev>
 <96e0ea70-291e-4f0a-b449-acbaef16c099@bastelstu.be>
 <76059dd0-d27a-4207-9460-658175f54a99@app.fastmail.com>
 <CAKz+gELLgydTOh_fA97Z0-XJ1FcseJHq3TTSACp9YTO43+TXpg@mail.gmail.com>
 <5A1B6BCB-97AC-4D50-A38C-C7EE394E4EE1@nicksdot.dev>
 <ba592eb4-5f93-462f-a7bd-84836e53d3c6@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Jul 20, 2025, at 3:54 AM, Niels Dossche wrote:

>> When is a discussion allowed to be considered wound down?=C2=A0

> This has never been defined and always has a subjective part.
> In general, no one will block you from bringing it to a vote if no=20
> substantial changes have been made to the RFC and the discussion laste=
d=20
> at least 2 weeks.

Indeed, and I've been yelled at in the past for making non-trivial chang=
es to an RFC "too close" to when the vote is called.  (For some undefine=
d definition of "too close.")

> Note though that the fact that the RFC still includes this does show a=20
> non-consensus from the authors PoV.
> Either you fully stand behind your own RFC and wouldn't have split the=20
> vote, or you agreed that the get hook is a bad idea.
> In the latter case, why even include this still in the RFC text,=20
> especially after Larry said he's positive that part won't pass?
> This comes across as really wanting something of the RFC to pass, not=20
> aiming for the best "solution".

No, we split the vote because, as stated, based on the available evidenc=
e (this list) "set" appears to be uncontroversial, but "get" is.  But ri=
pping out half the RFC right before calling a vote would certainly quali=
fy as a not-small change, and if we want to get the "set" portion into 8=
.5, we have a short window before a vote can be called.  Hence, splittin=
g the vote, which is the smaller change.  Submitting essentially a new R=
FC at this point isn't really an option.

If by some miracle the 'get' hook also passes, I'm OK with that.  But it=
's hardly the first vote that's been started despite considerable opposi=
tion.

I do not recall seeing anyone make a compelling argument against readonl=
y 'set' hooks, so at the moment it does look to us like allowing set hoo=
ks, at least, is a "best solution."  (Or at least, best presented so far=
.)

The idea that a split vote means the authors don't support their own RFC=
 is nonsensical, given that multi-part votes or split votes or secondary=
 votes come up multiple times every release.  Rather, it means the diffe=
rent parts are related enough and small enough to be digestible in a sin=
gle RFC, but each can stand on their own if necessary.  In this case, no=
thing about the get hook necessitates a set hook, and nothing about the =
set hook necessitates the get hook.

--Larry Garfield