Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127749
Precedence: bulk
MIME-Version: 1.0
References: <YaJrvr69GYjTEI8_yULnrtV4XjfR2tfQIBBGtJrLH_dO62WsKXcmMdUCk-FaPMIilVRlQWX5BZleaxBcCinSwmfMnJR_-whG2jLSflKN85E=@gpb.moe>
 <2108D675-AEF0-410B-9BD1-E68BFEBE4F9B@cschneid.com>
In-Reply-To: <2108D675-AEF0-410B-9BD1-E68BFEBE4F9B@cschneid.com>
Date: Wed, 25 Jun 2025 14:21:22 +0200
Message-ID: <CAB-BujZDrCRUfgmfucPoFZRUWsGCjCJ2MtX7gFi=-6keiDedMQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Make Reflection*::getDocComment() return an empty
 string instead of false
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: andreas@dqxtech.net (Andreas Hennings)

On Wed, 25 Jun 2025 at 13:56, Christian Schneider <cschneid@cschneid.com> wrote:
>
> Am 25.06.2025 um 12:37 schrieb Gina P. Banyard <internals@gpb.moe>:
> > While working on the deprecation to/from bool type juggling in functions RFC and seeing the impact within Symfony, we found a common slightly annoying case.
> > The getDocComment method of various Reflection classes was always used as a string, and we thought changing the behaviour in PHP made more sense.
> >
> > I submitted a PR [1] but was asked to gather feedback on the mailing list.
> >
> > Please let me know what you think.
>
> In general I like out-of-band instead of in-band signalling as it seems more robust to me.

I agree with this.
I was not familiar with the terms, but they make a lot of sense.
This said, I have experienced that some people feel different, and
want to return '' all the time..

In general, "return null" becomes more valuable if an empty string
would have a different meaning.
In this case, an existing doc comment can never be an empty string. So
there is no ambiguity if we would use ''.
But semantically, I think of "no doc comment" as different from "empty
doc comment", and null (or false) reflects that better than an empty
string.

>
> I am a bit confused why it was false in the first place and not null as the absence of something was in my book the definition of null.
> But then again I realise there is a general aversion against null.

I think false is just "legacy null" for a lot of php built-in
functions and methods.
Any argument for the aversion to null would equally apply to false,
when used as a "not found" value.

If starting from scratch, I would prefer "return null" in all of those
places. But at this point I don't think the BC break is worth it, so
the "return false" will follow us around for a long time.

(The BC break applies to extending and to conditonal checks with === false)

>
> I noticed that the "empty string for absence of value" was also used in DOMElement::getAttribute() but you can argue that the existence of DOMElement::hasAttribute() fills this gap.

I think all this shows is that different parts of php were created by
different people, or that somebody changed their mind over time.
To me, "return null" would be preferable for
DOMElement::getAttribute(). https://3v4l.org/QHXlA

Cheers
Andreas

>
> Anyway, I'm not a big fan of this move but won't fight it either.
>
> Regards,
> - Chris