Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110955
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-ID: <bd94ee30-7871-4686-b43d-f1299f5371cc@www.fastmail.com>
In-Reply-To: <65EE4215-3F80-435C-B271-DBE30D26E2CB@joshbruce.dev>
References: <65EE4215-3F80-435C-B271-DBE30D26E2CB@joshbruce.dev>
Date: Sat, 11 Jul 2020 15:02:36 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 8, 2020, at 11:39 AM, Josh Bruce wrote:
> Link to working draft: https://bit.ly/php-0001 <https://bit.ly/php-000=
1>
>=20
> Discussion on implementing a means by which a class instance can=20
> interacted with syntactically as a boolean.
>=20
> At this point in the discuss the only means discussed is creation of a=
=20
> method (magic or via an interface).
>=20
> Ability to cast is not ruled out.=20
>=20
> And, my limited knowledge of PHP at this depth, much less under the=20=

> hood, means there could be a lot of unknown unknowns regarding the way=
s=20
> a boolean can be interpreted and interacted with; therefore, those may=
=20
> not be covered at this time.
>=20
> I=E2=80=99m also not liking the overly contrived nature of the samples=
 and will=20
> improve those over time should interest maintain or increase.
>=20
> Cheers,
> Josh
>=20
> ps. If you have any feedback or information on social interactions her=
e=20
> that might help, please do let me know, normally I would have watched=20=

> for a while before putting my foot in - hopefully it doesn=E2=80=99t e=
nd up in=20
> my mouth. :)

Hi Josh.

Your social interactions seem fine, no worries. :-)  You may need to ask=
 for wiki access; the configuration/rules around it are, honestly, kinda=
 weird.

To the RFC itself, as you've likely noticed you've stumbled into a long-=
running contentious question.  __toString() is itself already controvers=
ial and some don't like it, while others want to see every possible prim=
itive type added for completeness.

Focusing on Bool is, I think, a good choice because it has an argument f=
or it other than "well it works for strings."  You hint at it in the wri=
teup but really bury the lead: Null objects.

Being able to not use null or false as a "not found" case and instead re=
turn an "empty" value object is very nice, but then you also want to kno=
w if the value returned is legitimate.  An object that could self-cast t=
o boolean makes something like this viable and type-safe:

$user =3D $repo->getUserById(5);
if ($user) {
  // Do stuff with user
}
else {
  // The user wasn't found.
}

No exception needed, no null, no false, just a safe "empty" user object;=
 whether you want to branch the logic based on that is then up to the ca=
ller.  It also allows an "empty" object to still have default values ins=
ide it (like a username of "Anonymous" or something), which are up to th=
e implementer.

I'd say focus on that benefit.  The similarity to __toString() is just t=
o show that the implementation is consistent with existing patterns, not=
 an argument for adding _toBool() itself.  Feel free to steal the user-r=
epo example if you want.

I have no strong feelings about interface vs. magic method, that's an ol=
d race I don't have a horse in.

--Larry Garfield