Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121757
MIME-Version: 1.0
References: <2b4591c1-f999-49b5-8061-67db816aa0da@gmail.com>
 <054a1e3e-f860-4596-83a9-9f557c6fd316@gmail.com> <4c5c9209-e797-49f3-84a8-f8c2371b34d1@app.fastmail.com>
In-Reply-To: <4c5c9209-e797-49f3-84a8-f8c2371b34d1@app.fastmail.com>
Date: Wed, 22 Nov 2023 15:12:09 +0100
Message-ID: <CAOWwgpnFMtmcojzktbD-P0_rt7tPx8gCcJvku+QYy3io79Oi8g@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>, Rowan Collins <rowan.collins@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000be838d060abe4e13"
Subject: Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000be838d060abe4e13
Content-Type: text/plain; charset="UTF-8"

Hi Rowan, Larry,

Thanks for the RFC.

I think there is an inaccuracy that needs to be fixed in the after-unset
state : as noted later in the RFC, magic accessors are called after an
unset($this->typedProps). This means the state cannot be described as
identical ("uninitialized') before and after unset() in the first table in
the RFC. Isn't there some vocabulary in the source that we can use  to
describe those states more accurately?

My initial gut reaction is that both ReflectionParameter and
> ReflectionProperty should treat "omitted" as "mixed", and just evaluate
> their type to "mixed".  It is in practice a distinction without meaning, or
> will be after this RFC.  That said, I also have an itch telling me that
> there are a few small-but-important edge cases where you would care about
> the difference between mixed and none in reflection, and that I'd be the
> one to run into them, but I cannot think of what they would be.
>


I think this needs to be clarified. I can't think of when this difference
could matter. I never wrote any code that could give any meaning to mixed
vs untyped properties, and many here know that I can write unusual PHP
code. I actually always wondered why we have this difference and I
therefore welcome the RFC.

Maybe this can be evaluated up to the point where we realize that the
change could go into 8.4?
I'd be happy to run a patched PHP on some codebases I maintain to see how
it goes.

Nicolas

--000000000000be838d060abe4e13--