Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128144 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 1F7F51A00BC for ; Sun, 20 Jul 2025 14:05:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1753020201; bh=/Dld8H/NkAdsrFikmhO6SWnqcr6MJNIDb7/RCXPKF60=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=MFg+62MUTta0yPi5kQHpk9wukvqH4kvj4Y3Vqw92eCWkAmm9Mgp4fPHtkUtGXQN9U xUG41X89mQVGR15yM6ZqrKUv8/L0pB/Cxk/WipiQJdk4AF7IewsFUMOPjyXyZ/Gzhn j15biR+M3GYOCOuYAFWsKw8q9dGMUmUlc4ZQULvMG3wVrUPbVcgNwZAPG8KT2p/nOg ZiQh8uPOR2273Y37DCtDkP94ZlAnfs1E9jafXngS1ASMvGw5lr+71Hg6RVqvhXaMDH aKHp7yAyzTsvZHEsnx2AKpvyV52exgGOaNYTtjVvbLHdT5SjcnVOTXpzPBJcwdt5S0 UUXBIHWTIgLXQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2E91D18005B for ; Sun, 20 Jul 2025 14:03:20 +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.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,HTML_MESSAGE, 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 avril.gn2.hosting (avril.gn2.hosting [84.19.162.247]) (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 ; Sun, 20 Jul 2025 14:03:19 +0000 (UTC) Received: from avril.gn2.hosting (localhost [127.0.0.1]) by avril.gn2.hosting (Postfix) with ESMTP id A46101C40C42; Sun, 20 Jul 2025 16:05:02 +0200 (CEST) Received: from smtpclient.apple (unknown [202.46.151.141]) by avril.gn2.hosting (Postfix) with ESMTPSA id CC8871C40166; Sun, 20 Jul 2025 16:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nicksdot.dev; s=default; t=1753020302; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v4qwRk+mDGCgfJQTSgeWugym4aqXdyyR565KhUcEkwA=; b=BZgygALy7WshnAzBaw+bOm4QIkPGvZ4ilkGNF/i+n0Zlg6/N2qyV04FhA4XTZTZ3wsJrfQ I4SWYUbZGd+/GAhTdCs/7YzmFiwzcEs5WlVfDf5P8DSFdXDNV3fUDj8y+uTT1T8GwYWPkk EE7bt5fEMnlx5C3JZyxR2spoPjFm5mORNkslZJDdJ37P/6Q1/rmaf6bKYBifZpsarRVAsK rEbBgbHSgPuuhseZHcddc+APLwg0w9kBmBzFewjhugSpD1COVJJghTeld0W4//VzBjmUTc r6XEQN2NwlBb1EIyaqJ/bH/Ks1DVvi/ZHBwx9dmar/QGjIFsRZDMSQj+vYRADg== Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_4C2C3F7C-E989-43B7-A11B-BAED623B5892" 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: Sun, 20 Jul 2025 21:04:43 +0700 In-Reply-To: Cc: php internals To: Niels Dossche References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com> <13B58381-AA61-4D38-A688-DD9E367ADE6F@nicksdot.dev> <96e0ea70-291e-4f0a-b449-acbaef16c099@bastelstu.be> <76059dd0-d27a-4207-9460-658175f54a99@app.fastmail.com> <5A1B6BCB-97AC-4D50-A38C-C7EE394E4EE1@nicksdot.dev> X-Mailer: Apple Mail (2.3826.600.51.1.1) From: php@nicksdot.dev (Nick) --Apple-Mail=_4C2C3F7C-E989-43B7-A11B-BAED623B5892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20. Jul 2025, at 15:54, Niels Dossche = wrote: >=20 > On 20/07/2025 02:58, Nick wrote: >>=20 >> Hey Niels, >>=20 >=20 > Hey Nick Hey Nils, >> The whole controversy is about `get`.=20 >>=20 >=20 > That's true. > Note though that the fact that the RFC still includes this does show a = non-consensus from the authors PoV. > Either you fully stand behind your own RFC and wouldn't have split the = vote, or you agreed that the get hook is a bad idea. This is a misinterpretation. > In the latter case, why even include this still in the RFC text, = 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 = aiming for the best "solution". Yes, we really want the `set` part to pass. No, this does not mean that we not aim for the best solution.=20 We listened to feedback and adjusted the voting structure accordingly. Please don=E2=80=99t forget that some people here support the RFC as is. As far as my understanding goes the list discussion is not a pre-vote. The vote will show what the majority, including the silent part, wants. There is, in my opinion, no need to patronise and prevent them from = voting for what they want. >> We addressed this by switching to a split vote, because literally all = those concerns/opinions (allow it; don=E2=80=99t allow it; add `init` = instead; cache it; don=E2=80=99t cache it) can _for now_ be = =E2=80=9Caddressed=E2=80=9D with a =E2=80=9Cno=E2=80=9D-vote on `get`, = and then follow up with a new `get` RFC later. >>=20 >=20 > It's important to plan for the future and come up with a holistic = solution. > I don't want to end up in a situation where in hindsight we shouldn't = have allowed a "set hook" for example and should've just left readonly = alone. I honestly cannot come up with a reason for why this would be the case. >> Am I wrong? >>=20 >>=20 >> What is this all about now? >>=20 >> What are we doing now?=20 >>=20 >>=20 >> Do we keep repeating the same arguments, and disallow bringing this = to vote at all? Even though like literally everyone seems to be on board = with =E2=80=9C`set` is ok=E2=80=9D?=20 >=20 > I believe I answered this, but just to make it extra clear: you are = allowed to bring this to a vote, no one can veto you for that. > I don't believe everyone (who replied) is pro "set hook". And = definitely not in other channels. You asked to seek =E2=80=9Cclear consensus=E2=80=9D. I am and was happy = to take all opinions into account. So, I think I did that. I, naturally, cannot take any opinions into account I am not aware of = because they were expressed in =E2=80=9Cother channels=E2=80=9D. Here, on-list, everyone seems to be on board. And that=E2=80=99s what I = can work with. > I'll end with saying that this should not discourage you from = interacting with the ML. I appreciate the consideration! Everything is ok.=20 Not succeeding will not hurt my feelings, and I=E2=80=99ll stick around.=20= > You got a bit "unlucky" with the subjects you chose as both hooks and = readonly are a bit controversial topics to begin with. In retrospective I am very aware of that! =F0=9F=98=85 > Kind regards > Niels Cheers, Nick --Apple-Mail=_4C2C3F7C-E989-43B7-A11B-BAED623B5892 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 20. Jul 2025, at 15:54, Niels Dossche = <dossche.niels@gmail.com> wrote:

On 20/07/2025 02:58, Nick wrote:

Hey Niels,


Hey = Nick

Hey = Nils,

The whole controversy is about = `get`. 


That's = true.
Note though that the = fact that the RFC still includes this does show a non-consensus from the = authors PoV.
Either you fully stand behind your own RFC = and wouldn't have split the vote, or you agreed that the get hook is a = bad idea.

This is a = misinterpretation.

In the latter case, why even include this = still in the RFC text, 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 aiming = for the best "solution".

Yes, we really want = the `set` part to pass.
No, this does not mean that we not aim = for the best solution. 
We listened to feedback and = adjusted the voting structure = accordingly.

Please don=E2=80=99t forget that = some people here support the RFC as is.
As far as my = understanding goes the list discussion is not a = pre-vote.

The vote will show what the majority, = including the silent part, wants.
There is, in my opinion, no = need to patronise and prevent them from voting for what they = want.

We addressed this by switching to a split vote, because literally = all those concerns/opinions (allow it; don=E2=80=99t allow it; add = `init` instead; cache it; don=E2=80=99t cache it) can _for now_ be = =E2=80=9Caddressed=E2=80=9D with a =E2=80=9Cno=E2=80=9D-vote on `get`, = and then follow up with a new `get` RFC = later.


It's = important to plan for the future and come up with a holistic = solution.
I don't want to end up = in a situation where in hindsight we shouldn't have allowed a "set hook" = for example and should've just left readonly alone.

I honestly cannot come up with = a reason for why this would be the case.

Am I wrong?


What is this all about = now?

What are we doing now? 


Do we keep repeating = the same arguments, and disallow bringing this to vote at all? Even = though like literally everyone seems to be on board with =E2=80=9C`set` = is ok=E2=80=9D? 

I = believe I answered this, but just to make it extra clear: you are = allowed to bring this to a vote, no one can veto you for that.
I don't believe everyone (who replied) is = pro "set hook". And definitely not in other channels.

You asked to seek =E2=80=9Cc= lear consensus=E2=80=9D. I am and was happy to take all opinions into = account. So, I think I did that.
I, naturally, cannot take any = opinions into account I am not aware of because they were expressed in = =E2=80=9Cother channels=E2=80=9D.
Here, on-list, everyone = seems to be on board. And that=E2=80=99s what I can work = with.

I'll end with saying that this should not = discourage you from interacting with the ML.

I appreciate the = consideration! Everything is ok. 
Not succeeding will not = hurt my feelings, and I=E2=80=99ll stick = around. 

You got a bit "unlucky" with the subjects = you chose as both hooks and readonly are a bit controversial topics to = begin with.

In retrospective I am very = aware of that! =F0=9F=98=85

Kind regards
Niels

Cheers,<= /div>
Nick

= --Apple-Mail=_4C2C3F7C-E989-43B7-A11B-BAED623B5892--