Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114618
MIME-Version: 1.0
References: <CAOwTYAtc_xD6n=efmamkAy4ro4KqPKxq18-zXsNriY0280FY2g@mail.gmail.com>
 <CABdc3WrwPZJcYnuaaPh6Q0Y60nED0ie3xOAQcZTNJiDtPqSY0g@mail.gmail.com>
In-Reply-To: <CABdc3WrwPZJcYnuaaPh6Q0Y60nED0ie3xOAQcZTNJiDtPqSY0g@mail.gmail.com>
Date: Wed, 26 May 2021 15:21:47 +0200
Message-ID: <CAOwTYAupBxi02PNHM4FFx73wW8CbwNBic2SHPY94cVRKnVFjPQ@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fed3be05c33b8614"
Subject: Re: [PHP-DEV] Consensus Gathering: is_initialized
From: krakjoe@gmail.com (Joe Watkins)

--000000000000fed3be05c33b8614
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Michal for input ...

> Ack, but real-world impact seems irrelevant? I've worked on stuff that
heavily relies on checking initialized state, and most of it is mostly
unaffected.
"meaningful benchmark" means "here's a use-case that really needs
`is_initialized()`, and absolutely cannot run into the penalties of
`ReflectionProperty#isInitialized()`

So what I hear you saying is that perf is actually irrelevant regardless of
what kind of benchmark you want to do ...

> Sounds weird? Why would a narrower version be needed at all?

The pattern ReflectionProperty#isInitialized() doesn't allow you to access
inaccessible properties without first setting them accessible, so that part
is not really different.

The scope could be extended to include untyped properties, but extending as
far as dynamic properties makes no sense because there's not going to be a
significant advantage - it would be doing the same work in the same way as
Reflector::IsInitialized.

I thought keeping scope as narrow as possible was better, but I can have my
mind changed on untyped properties, if that would make the difference
between you saying it's good or bad.

FWIW I've pretty much talked myself out of it at this point already ... I'm
hearing what I expected to hear.

Cheers
Joe


On Wed, 26 May 2021 at 14:57, Micha=C5=82 Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

>
>
> =C5=9Br., 26 maj 2021 o 12:14 Joe Watkins <krakjoe@php.net> napisa=C5=82(=
a):
>
>> Hi internals,
>>
>> In response to: https://bugs.php.net/bug.php?id=3D78480
>>
>> I implemented: https://github.com/php/php-src/pull/7029
>>
>> Not absolutely convinced that it's a good idea, I asked Nikita to review=
,
>> and he's unconvinced also and suggested a discussion should be started.
>>
>> You can read both of our thoughts about it on the PR.
>>
>> What I'm looking for now, is reasons that we are wrong - good use cases
>> that aren't born from code that is doing bad things ...
>>
>
> IMHO we don't need it, working with the typed properties since the
> beginning
> I thought only for a short period that I'd need this kind of feature but
> shortly realized
> that I'm doing it wrong if my code can reach such state,
> given that all paths now lead to a known state,
> object construction in all cases specifies all required properties
> without having any doubts like uninitialized properties so this is doable=
.
>
> If one really needs to check if a property is initialized or not I
> consider it a dark magic
> and such can reach up to the reflection mechanism to just check it.
> IMHO it's not common (or at least should not be) to have such a need.
>
> Cheers,
> Micha=C5=82 Marcin Brzuchalski
>

--000000000000fed3be05c33b8614--