Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110975
Message-ID: <820338EF-AD7C-4AD2-9305-8F814FA163D7@joshbruce.dev>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C4E040D2-3D3E-4F79-9283-7455998CAC5E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 10:33:39 -0500
In-Reply-To: <CAF+90c-ayB43unWK8x=PRmnSCv5jp7jekGwNbstmiWxLxt2fXw@mail.gmail.com>
Cc: php internals <internals@lists.php.net>
To: Nikita Popov <nikita.ppv@gmail.com>
References: <7238EFA9-8BE4-48E2-B6C6-6C3E14CFA208@joshbruce.dev>
 <CAF+90c-ayB43unWK8x=PRmnSCv5jp7jekGwNbstmiWxLxt2fXw@mail.gmail.com>
Subject: Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declare
 emptiness and by extension truthiness
From: josh@joshbruce.dev (Josh Bruce)

--Apple-Mail=_C4E040D2-3D3E-4F79-9283-7455998CAC5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


>=20
> Latest version as we zero in on what this is really about: =
https://bit.ly/php-0002 <https://bit.ly/php-0002> =
<https://bit.ly/php-0002 <https://bit.ly/php-0002>>
>=20
> I have a really hard time understanding what is actually being =
proposed here. You mention the introduction of the Emptiable interface, =
but not how 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 though.
>=20
> Some thoughts on the general domain:
>=20
> 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.
>=20

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 =
casting to bool (__toBool or something). After a couple rounds the =
relationship between empty() and bool surfaced. The question I=E2=80=99m =
volleying there is are they different concepts (a non-answer compared to =
a lie) and does it matter given the established norm. (Sounds like =
you=E2=80=99re in the established norm camp - I tend to lean that way as =
well.)

> 2. Coupling boolean casts to an "emptiness" concept seems somewhat =
dubious 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 make 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.

>=20
> 3. I'm generally not a fan of overloadable bool casts. We have exactly =
one 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 =
what problems people are running into and how it=E2=80=99s implemented - =
at least 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=99=
ll 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 =
earlier 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

}

I remember hearing what sounds like hyperbole but it said something like =
40% of code written is guarding against null. I can totally see that =
being real so didn=E2=80=99t look much further into it. If we can =
guarantee that an object is that type of object - just happens to be =
empty, maybe we reduce or remove the need null-checks??

Cheers,
Josh


--Apple-Mail=_C4E040D2-3D3E-4F79-9283-7455998CAC5E--