Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118957
Message-ID: <F6F7D548-8499-480F-8B18-0ABD0EAA5276@joshbruce.dev>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FA076732-25DA-4BFA-B2EE-3E794F108CE7"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Date: Thu, 3 Nov 2022 20:01:35 -0400
In-Reply-To: <C406C2F8-02AE-4495-A067-A6BC9DE9ED49@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>,
 =?utf-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>,
 php internals <internals@lists.php.net>
To: Claude Pache <claude.pache@gmail.com>
References: <21C5073D-3F39-49DA-8686-E027AE780793@joshbruce.dev>
 <D14A346D-6234-4A85-9266-4125236B3F3E@joshbruce.dev>
 <1bc7759a-63b8-4b96-bb69-97b50f851307@www.fastmail.com>
 <E6C6FE8B-C263-46AB-B851-14DEB4AED52A@joshbruce.dev>
 <DM6PR07MB66189EA71A5EBDFD16CEDC05F9470@DM6PR07MB6618.namprd07.prod.outlook.com>
 <C3C433DA-B9C0-4B49-98C7-9D163AF713F9@joshbruce.dev>
 <94DC0839-E43B-4F3A-9105-8F3CB9D7BBC1@joshbruce.dev>
 <B061594C-7516-412E-AEAA-61BE25938377@joshbruce.dev>
 <CABdc3WrDAE0Af+kY+6myAzJDJcLpNyU8ebODxbs2tXF3w9GNQg@mail.gmail.com>
 <9AE33306-ED89-4FE4-86A5-89B4EDC81545@gmail.com>
 <CADyq6sK+MEsG=U58XnkEyRRyw_a0Zt=wxUr4UWRM9JDG_wCfnA@mail.gmail.com>
 <13A9249B-C3B2-46E3-AB50-D46FAA2A301E@joshbruce.dev>
 <C406C2F8-02AE-4495-A067-A6BC9DE9ED49@gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
From: josh@joshbruce.dev (Josh Bruce)

--Apple-Mail=_FA076732-25DA-4BFA-B2EE-3E794F108CE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

>  while declaring an object falsifiable changes the semantics of `if =
($obj)`.

Got me thinking, appreciate that.=20

In PHP:=20

false =3D=3D empty =3D=3D null=20

(Originally the RFC was geared toward data objects being able to =
natively express emptiness when passed to empty() - might be beneficial =
for the SimpleXMLElement topic - conversation revealed false and empty =
are tightly coupled in PHP and the preference was to declare false =
instead of empty to cover more use cases, including empty().)

I=E2=80=99m not sure how much if ($obj) actually changes what we do at a =
fundamental level - due to the true/false (null) caveat:

> Today, in a common situation where I know that a variable contains =
either an object of some type or null [=E2=80=A6]
> unless I have carefully read the docs in order to know whether they =
have opt into that misfeature, and, if so, what exactly =E2=80=9Cfalsy=E2=80=
=9D means for them (invalid?, empty?, zero?).

Do you still find yourself reading the docs or debugging to figure out =
why the thing became null instead of another, expected type (I do)?

Asked in a different way, with or without the RFC, I still need to know =
if the implementer has opted in to using null (or empty or false), and =
under what circumstances I would receive null (or empty or false), yeah?

Default behavior is:

if (new MyType($config)) {
  // do something with not null - true - can=E2=80=99t use object =
because unassigned

}
// code is unreachable because instances always resolve to true unless =
an exception occurs during initialization; the guard is somewhat =
unnecessary.

Given the default behavior, would we consider a static initializer =
returning MyType|null or ?MyType to be an anti-pattern =
(=E2=80=9Cmisfeature=E2=80=9D), because __construct can=E2=80=99t return =
null (or false or anything else really)?

We could also throw during initialization; see Stripe: =
https://github.com/stripe/stripe-php/blob/9c7e27ab7e30a50853aa23139d581cea=
b3b5e619/lib/BaseStripeClient.php#L254

try {
  $obj =3D new MyType($config);

  // handle true - able to use $obj

} catch ($e) {
  // handle false - object type we interact with is the error - not null =
and not $obj, but still represents false because the unintended occurred

}

Or we could opt in to returning the instance of the error directly, =
without throwing: MyType|MyError - user would still need to guard in =
some way - using is_a() possibly - see null objects: =
https://en.wikipedia.org/wiki/Null_object_pattern

Shifting gears.

Consider a situation where there=E2=80=99s a range of true and false =
within the object definition; PSR-7 responses due to HTTP status codes: =
https://www.php-fig.org/psr/psr-7/ and =
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

if ($response->getStatusCode() > 199 and $response->getStatusCode() < =
300) {
  // do something with =E2=80=9Ctrue=E2=80=9D - which has a range of 100 =
possibilities at a granular level, which we could respond to differently =
- possible to interact with $response

}
// do something with =E2=80=9Cfalse=E2=80=9D - which has a range of more =
than 100 possibilities at a granular level, which we could respond to =
differently - possible to interact with $response

We might wrap response to create an isOk() method to move the =
conditional logic somewhere within the object itself and make the call =
site more readable.

If ($response->isOk()) {
  // do something with =E2=80=9Ctrue=E2=80=9D - still able to interact =
with $response

}
// do something with =E2=80=9Cfalse=E2=80=9D - still able to interact =
with $response

With the RFC:

if (new MyType($config)) {
  // do something with =E2=80=9Ctrue=E2=80=9D - can=E2=80=99t use MyType =
because not assigned

}
// reachable because possible to resolve to false - if implements =
Falsifiable and __toBool can resolve to false - can=E2=80=99t use MyType =
because not assigned

if ($response =3D new MyType($config)) {
  // do something with =E2=80=9Ctrue=E2=80=9D - with the option of using =
$response

}
// reachable - can=E2=80=99t use MyType because may not be assigned

$response =3D new MyType($config);
If ($response) {
  // do something with =E2=80=9Ctrue=E2=80=9D - with the option of using =
$response

}
// do something with =E2=80=9Cfalse=E2=80=9D - with the option of using =
$response

Or a host of other possibilities for the conditional guard.

They=E2=80=99re all shorthands for the same, high-level concept - does =
this thing resolve to true *or* false (null), yeah?

Cheers,
Josh

ps.=20

Added open issue of what to do with callable: =
https://wiki.php.net/rfc/objects-can-be-falsifiable - specifically in =
the context of __invoke()

Added invokable RFC to RFC list.

> On Nov 3, 2022, at 4:30 AM, Claude Pache <claude.pache@gmail.com> =
wrote:
>=20
>=20
>=20
>> Le 3 nov. 2022 =C3=A0 02:51, Josh Bruce <josh@joshbruce.dev =
<mailto:josh@joshbruce.dev>> a =C3=A9crit :
>>=20
>> Similar to:
>>=20
>> function x(?SomeType $arg): ?SomeOtherType
>>=20
>> Instead of:
>>=20
>> function x(SomeType|null $arg): SomeType|null
>>=20
>> Both are the same thing under the hood.
>=20
> The big difference between `?SomeType` shortcut and falsifiable object =
feature, is that using `?SomeType` does not change the semantics of =
`SomeType|null`, while declaring an object falsifiable changes the =
semantics of `if ($obj)`.
>=20
>>=20
>> In that same spirit, totally opt-in - not required to use or you can =
get there some other way - similar to Marco=E2=80=99s comment around =
__toString.=20
>=20
>=20
>=20
> It is opt-in for the implementer of the library, not for the user of =
it, as they are not necessarily the same person.
>=20
> Today, in a common situation where I know that a variable contains =
either an object of some type or null, I routinely write `if ($a)` to =
mean `if ($a !=3D=3D null)`. Now, with magic `__toBool()` possibly =
implemented by  the library=E2=80=99s author, I don=E2=80=99t know what =
`if ($a)` means, unless I have carefully read the docs in order to know =
whether they have opt into that misfeature, and, if so, what exactly =
=E2=80=9Cfalsy=E2=80=9D means for them (invalid?, empty?, zero?). =
Ironically, that will incite me to not use anymore the implicit casting =
to bool for objects, and to write systematically `if ($a !=3D=3D null)`, =
so that both myself and the reader of my code won=E2=80=99t have to look =
at the docs in order to understand such simple code.
>=20
> =E2=80=94Claude


--Apple-Mail=_FA076732-25DA-4BFA-B2EE-3E794F108CE7--