Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118971
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
In-Reply-To: <CABdc3WqePKe8Br1d_qEA9f=PK5L46tRi3ANXzxDd3UmiU8b3Zg@mail.gmail.com>
Date: Fri, 4 Nov 2022 19:05:06 -0400
Cc: Claude Pache <claude.pache@gmail.com>,
 Marco Pivetta <ocramius@gmail.com>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3D76083B-6742-4026-824C-30458B110FEC@joshbruce.dev>
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>
 <F6F7D548-8499-480F-8B18-0ABD0EAA5276@joshbruce.dev>
 <CABdc3WqePKe8Br1d_qEA9f=PK5L46tRi3ANXzxDd3UmiU8b3Zg@mail.gmail.com>
To: =?utf-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
From: josh@joshbruce.dev (Josh Bruce)

> While I understand the proposed feature is opt-int it introduces more =
magic
> that can be solved using more verbose and IMO cleaner solutions.

Understood and appreciate the position.

> This is somehow confusing, why is the $response storing object ref is =
ok
> while inclining the new object creation is not?

Not quite following, apologies.

Adding a different use case.

Allow for fully-specified custom collections; array being the compound =
type that can resolve to false/empty based on count.

$array =3D [];

(bool) $array; // false

empty($array); // true

if ($array) {=20
  // handle not empty=20
}=20
// handle empty

$array =3D [1, 2, 3];

(bool) $array; // true

empty($array); // false

if ($array) {=20
  // handle not empty=20
}=20
// handle empty

Current state of PHP re custom collections (exclamation marks - ! - =
represent difference compared to native array):

class MyCollection implements ArrayAccess, Iterator, Countable {}

$collection =3D new MyCollection([]);

(bool) $collection; // true - ! - because instance exists, regardless of =
collection content

empty($collection); // false - ! - same reason as previous

if ($collection) {=20
  // ! - handle empty and not empty=20
}=20
// ! - unreachable

$collection =3D new MyCollection([1, 2, 3]);

(bool) $collection; // true - because instance exists, regardless of =
collection content

empty($collection); // false - same as previous

if ($collection) {=20
  // ! - handle empty and not empty=20
}=20
// ! - unreachable

With RFC:

class MyCollection implements ArrayAccess, Iterator, Countable, =
Falsifiable=20
{
  public function __toBool(): bool
  {
    return $this->count() > 0;
  } =20
}

$collection =3D new MyCollection([]);

(bool) $collection; // false - because collection count =3D=3D=3D 0 - =
close to the previous comment re single value under inspection

empty($colleciton); // true - same as previous

if ($collection) {=20
  // handle not empty=20
}=20
// handle empty

$collection =3D new MyCollection([1, 2, 3]);

(bool) $collection; // true - because collection count > 0

empty($colleciton); // false - same as previous

if ($collection) {=20
  // handle not empty=20
}=20
// handle empty

Alternative approaches for custom collection use case:=20

1. Modify Countable (most likely, if using alternative) to include =
empty() and bool() methods.=20

Might feel more palatable despite not strictly limiting scope to the =
custom collection use case.=20

Any class with Countable, for example, would also be able to resolve to =
false or empty using SPL functions - including use in IF.

Allows for explicit (=E2=80=9Cverbose"), direct call of both methods by =
user should they choose:

$collection->empty()

$collection->bool()

Instead of $collection->__toBool() OR something like =
$collection->__isEmpty()

Known drawback to using Countable would be in a possible future where =
there is a separation between 0, false, and empty when it comes to type =
juggling in PHP.=20

Whereas using a Falsifiable interface leaves a simpler path of an =
Emptiness interface; again, should the three be separated in the future.

2. Or, modify ArrayAccess to include the empty() and bool() methods.

This would restrict the behavior more toward the custom collection =
concept.

However, would lean more toward Countable due to the equivalence in PHP =
type juggling and Countable using an integer: 0 =3D=3D false =3D=3D =
empty

Otherwise, similar to alternative #1.

3. Or, modify Iterator to include the empty() and bool() methods (or =
possibly leverage the valid() method that already exists?); otherwise, =
similar to alternative #2.

Cheers,
Josh

> On Nov 4, 2022, at 1:37 AM, Micha=C5=82 Marcin Brzuchalski =
<michal.brzuchalski@gmail.com> wrote:
>=20
>>=20
>> 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
>>=20
>> }
>> // 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
>>=20
>> 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.
>>=20
>> If ($response->isOk()) {
>>  // do something with =E2=80=9Ctrue=E2=80=9D - still able to interact =
with $response
>>=20
>> }
>> // do something with =E2=80=9Cfalse=E2=80=9D - still able to interact =
with $response
>>=20
>=20
> This looks way much cleaner and is easy to read and understand.
> While I understand the proposed feature is opt-int it introduces more =
magic
> that can be solved using more verbose and IMO cleaner solutions.
>=20
>=20
>> With the RFC:
>>=20
>> if (new MyType($config)) {
>>  // do something with =E2=80=9Ctrue=E2=80=9D - can=E2=80=99t use =
MyType because not assigned
>>=20
>> }
>> // 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
>>=20
>> if ($response =3D new MyType($config)) {
>>  // do something with =E2=80=9Ctrue=E2=80=9D - with the option of =
using $response
>>=20
>> }
>> // reachable - can=E2=80=99t use MyType because may not be assigned
>>=20
>> $response =3D new MyType($config);
>> If ($response) {
>>  // do something with =E2=80=9Ctrue=E2=80=9D - with the option of =
using $response
>>=20
>> }
>> // do something with =E2=80=9Cfalse=E2=80=9D - with the option of =
using $response
>>=20
>=20
> This is somehow confusing, why is the $response storing object ref is =
ok
> while inclining the new object creation is not?
> This requires more attention while reading and debugging.
>=20
> Cheers,
> Micha=C5=82 Marcin Brzuchalski