Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110976
MIME-Version: 1.0
References: <7238EFA9-8BE4-48E2-B6C6-6C3E14CFA208@joshbruce.dev>
 <CAF+90c-ayB43unWK8x=PRmnSCv5jp7jekGwNbstmiWxLxt2fXw@mail.gmail.com> <820338EF-AD7C-4AD2-9305-8F814FA163D7@joshbruce.dev>
In-Reply-To: <820338EF-AD7C-4AD2-9305-8F814FA163D7@joshbruce.dev>
Date: Mon, 13 Jul 2020 18:50:30 +0200
Message-ID: <CAF+90c-VvnLHyBxC_Yxk9hsRN+fnAdjYHhQH2XT-uQ3JmiJgUg@mail.gmail.com>
To: Josh Bruce <josh@joshbruce.dev>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f8a37205aa557ddc"
Subject: Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declare
 emptiness and by extension truthiness
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f8a37205aa557ddc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 13, 2020 at 5:33 PM Josh Bruce <josh@joshbruce.dev> wrote:

>
>
>> Latest version as we zero in on what this is really about:
>> https://bit.ly/php-0002 <https://bit.ly/php-0002>
>>
>> I have a really hard time understanding what is actually being proposed
> here. You mention the introduction of the Emptiable interface, but not ho=
w
> it influences empty() or (bool) casts. There's some examples in "Usage"
> that are possibly intended to illustrate this -- I suspect that a "return
> true" vs "return false" mixup has made them impossible to understand thou=
gh.
>
> Some thoughts on the general domain:
>
> 1. I don't like the idea of decoupling empty() and (bool). empty($x) is
> currently the same as !$x (modulo notices), and changing that will make
> PHP's already messy implicit type conversion matrix even messier.
>
>
> Thanks for the feedback! Not all incorporated in the latest, due to
> timing: https://bit.ly/php-0002
>
> Initially this started as a desire to be able to declare an object castin=
g
> to bool (__toBool or something). After a couple rounds the relationship
> between empty() and bool surfaced. The question I=E2=80=99m volleying the=
re is are
> they different concepts (a non-answer compared to a lie) and does it matt=
er
> given the established norm. (Sounds like you=E2=80=99re in the establishe=
d norm
> camp - I tend to lean that way as well.)
>
> 2. Coupling boolean casts to an "emptiness" concept seems somewhat dubiou=
s
> to me. That works for container structures, but what about something like
> new Bigint(0)? It would be quite odd to declare an integer "empty" to mak=
e
> it evaluate to false.
>
>
> This seems counter to the first bullet point. They already are coupled.
> The result of empty() tends to be the opposite of casting bool - unless
> there=E2=80=99s an example I=E2=80=99m unaware of.
>

Yes, they are coupled. The problem here is more that empty() is a misnomer,
because it does not check emptiness, it checks falsyness. The big example
is that empty("0") returns true, even though "0" is very clearly not an
empty string.

>
> 3. I'm generally not a fan of overloadable bool casts. We have exactly on=
e
> object with an overloaded bool cast in PHP, and that's SimpleXMLElement. =
As
> far as I know, this has only caused issues. A big reason for that is that
> using "if ($foo->bar)" is a common idiom for checking "if ($foo->bar !=3D=
=3D
> null)" -- one that works very reliably, with the exception of
> SimpleXMLElement.
>
>
> I wasn=E2=80=99t aware of this. Thank you! I will take a look and see wha=
t
> problems people are running into and how it=E2=80=99s implemented - at le=
ast from a
> developer perspective.
>
> 4. I think if ($container->isEmpty()) is much clearer than if ($container=
)
> -- why would we want people to use the latter instead?
>
>
> Fair question. This made me raise the question in the draft and I=E2=80=
=99ll raise
> it here=E2=80=A6under what circumstances would PHP return null from new.
>
> $instance =3D new MyClass();
>
> If ($instance->isEmpty()) {}
>
> $inner =3D $instance->innerObject();
>
> If ($innnerObject->isEmpty()) {}
>
> If I implement the innerObject() method to return null - and it does -
> then that call fails, because it=E2=80=99s null, which brings up your ear=
lier
> point, I think.
>
> If ($innerObject) {
>   // not null
>
>   If ($innerObject->isEmpty()) {
>     // two-step process with null-check
>
>   }
> }
>
> // with the language feature
> If ($innerObject) {
>   // I know it can give and receive messages, and is not empty
>
> } else {
>   // I know it can give and receive messages, but is empty
>
> }
>

The nullsafe operator proposal will allow you to write this as

if ($innerObject?->isEmpty()) {

}

That is both concise, and very explicit. Just If ($innerObject) is not --
it could be intended as just a null check, or as a null or empty check, or
only an empty check, under your proposal.

Nikita

--000000000000f8a37205aa557ddc--