Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123122
Feedback-ID: id5114917:Fastmail
Date: Fri, 12 Apr 2024 14:27:29 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
User-Agent: K-9 Mail for Android
In-Reply-To: <66160A1D.4060409@adviesenzo.nl>
References: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com> <66154AA0.1040905@adviesenzo.nl> <66160A1D.4060409@adviesenzo.nl>
Message-ID: <237C3A81-2906-4108-A6E4-5BA4BE156D91@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 10 April 2024 04:40:13 BST, Juliette Reinders Folmer <php-internals_nos=
pam@adviesenzo=2Enl> wrote:

* Whether a type can be specified on the parameter on `set` depends on whe=
ther the property is typed=2E You cannot declare `set(mixed $value)` for an=
 untyped property, even though it would effectively be compatible=2E This i=
s inconsistent with the behaviour for, for instance method overloads, where=
 this is acceptable: https://3v4l=2Eorg/hbCor/rfc#vrfc=2Eproperty-hooks , t=
hough it is consistent with the behaviour of property overloads, where this=
 is not acceptable: https://3v4l=2Eorg/seDWM (anyone up for an RFC to fix t=
his inconsistency ?)



Just picking up on this point, because it's a bit of a tangle: PHP current=
ly makes a hard distinction between "typed properties" and "untyped propert=
ies"=2E For instance, unset() works differently, and the "readonly" attribu=
te can only be added to a typed property=2E

That's actually rather relevant to your point, because if this RFC passes =
we would probably need to consider that PHP has at least 4 types of propert=
ies:=20

- dynamic properties (deprecated by default, but allowed with an attribute=
)
- declared but untyped properties
- typed properties
- virtual properties

But maybe 6, with:=20

- untyped properties with hooks
- typed properties with hooks

Of course, most of the time, users aren't aware of the current 3-way split=
, and they won't need to think about all 6 of these variations=2E But there=
 are going to be cases where documentation or a future RFC has to cover edg=
e cases of each=2E

I do think there is scope for removing some features from the RFC which ar=
e nice but not essential, and reducing these combinations=2E For instance, =
if we limit the access to the underlying property, we might be able to trea=
t "virtual properties" as just an optimisation: the engine doesn't allocate=
 a property it knows will never be accessed, and accesses to it, e=2Eg=2E v=
ia reflection, just return "uninitialized"=2E

I am however conscious that RFCs have failed in the past for being "not co=
mplete enough" as well as for being "too complex"=2E

Regards,
Rowan Tommins
[IMSoP]