Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111049
Message-ID: <FAD3F09E-9712-4353-B5CC-AF635BF23B3E@joshbruce.dev>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8CE391CA-A49D-48F7-852A-27E4A7AFB5F4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 16 Jul 2020 10:28:47 -0500
In-Reply-To: <CAKuGYLRntk1i-9tUvwJktCOKHNeACdA9o1ksXX3cPBO3XMRevA@mail.gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
To: Matthew Brown <matthewmatthew@gmail.com>
References: <21C5073D-3F39-49DA-8686-E027AE780793@joshbruce.dev>
 <CAKuGYLT-31Bjav6bKBYDBqPc6wb41FzebzoSWBmt9+4=OdRAYA@mail.gmail.com>
 <132a2f9c-331c-48c9-8c15-f0f7c9392341@www.fastmail.com>
 <CAKuGYLRntk1i-9tUvwJktCOKHNeACdA9o1ksXX3cPBO3XMRevA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
From: josh@joshbruce.dev (Josh Bruce)

--Apple-Mail=_8CE391CA-A49D-48F7-852A-27E4A7AFB5F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

https://wiki.php.net/rfc/objects-can-be-falsifiable =
<https://wiki.php.net/rfc/objects-can-be-falsifiable>

Updates:

- Open issues (outstanding questions/concerns) updated
- Future scope
- References now have links to original copies on GitHub (still updating =
0002) - will be removed if accepted and implemented.
- No violent opposition, but concerns - will be looking at how to =
implement (or set up implementing).

All:

Trying to let conversation flow w/o me; sticking to once a day batch =
updates. Let me know if you=E2=80=99d prefer something else - still =
learning the Roman-way. :)

To Larry=E2=80=99s user example.=20

With Falsifiable the User instance becomes more self-aware. __toBool(), =
which might be more for the object itself, other objects, or PHP itself =
through a universal, reserved API entry point (like other magic =
methods).

Trying to make PHP fail gracefully more by adding to the ability of not =
returning null (or interacting with null - nullsafe, optionals, and so =
on).

(Maybe that should be a table as well??)

print null; // always succeeds despite being nothing - not a fatal error

(bool) null; // always succeeds - always false

(integer|float) null; // always succeeds - always 0

(array) null; // always succeeds - always []

(string) null; // always succeeds - always =E2=80=9C"

null->someMethod(); // always fails - crashes app

I was in the conversations leading up to null being able to handle this =
much interaction, part makes me go back to something talked about re new =
developers (paraphrased): It's frustrating to learn software development =
when it takes a lot to set up and with every turn you take your app =
crashes - people give up; so, PHP prefers failing gracefully over hard =
crashes.=20

The only interaction on null that seems to fail outright (from personal =
experience) is trying to call a method because it=E2=80=99s not an =
object. (It doesn=E2=80=99t even fail the dread array-to-string =
conversion. lol)

> I really appreciate any effort that can make PHP a more powerful =
language. However, for this item, I believe it will generate much =
greater cognitive complexity for new users (and I hate to assume that =
this is a problem, but we have to remember our roots).

David: Completely agree on respecting new users and devs (see opening =
bit).

I=E2=80=99m thinking right now, for me, it=E2=80=99s more about always =
being able to message the type you expect, even if false (in the =
abstract), while also letting PHP to interact automatically with it in =
the ways we have also become accustomed.=20

> (bool) cast working together with __toBool() is a good one, but I =
think that it is being discussed in another topic.

Was it an RFC or email??=20

If email and within the last week or so, it might be this same =
conversation.=20

Took a moment to evolve to this kinda hybrid approach. (In short, back =
to the original implementation, with a pretty different rationale.)

> The other implication is that this is now possibly *not* a bug:
>=20
> if (!$foo) {
>  $foo->bar();
> }

Matthew: I can see that feeling like a bug, for me it would be a feature =
(can=E2=80=99t believe I just said that).=20

Objects that return an abstracted (high-level) false, can tell me why =
(without blowing things up via fatal errors or added syntax and time of =
try-catch-throw or various permutations of optionals, which is possibly =
frustrating for new devs - possibly specific to the self-taught, it was =
for me back in the day - still don=E2=80=99t have the muscle memory for =
try-catch-throw and implementing errors).

I can=E2=80=99t ask null any questions - it exists only in the mind (so =
to speak), but I can send messages to an instance that is abstractly =
false. (And remove all the null-checks and optionals from (at least) my =
code that uses it or wraps some package that doesn=E2=80=99t.

My contract with a function call becomes: You will always get something =
of this type - period. Whether it=E2=80=99s the one you specifically =
wanted, that would be debatable, but it will be that type.

> "Further, the union type bool|Falsifiable will be dynamically added at =
run time to any object implementing the reserved __toBool() method, =
which would allow stdClass() objects to be defined as Falsifiable also. =
"
>=20
> What's that about?

Larry: Totally lifted from the Stringable RFC - lol: =
https://wiki.php.net/rfc/stringable =
<https://wiki.php.net/rfc/stringable> - string|Stringable

And I don=E2=80=99t know of a way to add an interface to `new =
stdClass()` - but thought this might be a valid use case:

$object =3D new \stdClass();
$object->__toBool =3D function() {=20
  return false|true;=20
};

if (! $object) {
  // made it
}

> "(Including __construct() replacing old style constructors in PHP 7.)" =
- __construct replaced old-style constructors in PHP 5. :-)

Here=E2=80=99s where I got that from: =
https://www.php.net/manual/en/migration70.deprecated.php =
<https://www.php.net/manual/en/migration70.deprecated.php>

Might have been tired when reading it. Are old style constructors still =
available at all in PHP 7 (just deprecated)?? Looking for when old =
constructors were removed - not just deprecated.

> I think the truth tables have a formatting error; check the last line =
that goes wider than the rest.  Also, watch out for "smart quotes" in =
the string parts.  Also, YAY summary tables!

Thanks for the table suggestion!=20

Not sure I=E2=80=99m getting the same issue. If you mean the line that =
starts with =E2=80=9Crow 1=E2=80=9D - this is a different paragraph, not =
part of the table - its width is styled wider than the table. =
Margin-bottom is 1.5rem on paragraph - 0 on the table; so, they butt =
against one another.

Is there a way to add an empty line (don=E2=80=99t recall seeing it in =
the wiki syntax)?? Or, are you noticing something else??

> Let's not confuse Java nullable issues with PHP nullability, which is =
quite
> healthy :-)


Marco: To be fair, I don=E2=80=99t know anything about Java=E2=80=99s =
nullable issues - only PHP's. :)

> BTW, I'm not saying you should pursue both RFCs or anything, that's
> just a reference in case you are looking around how others did it.=20

Marcio: Thanks for the example! I=E2=80=99ve never used a language that =
has this as a possibility by this type of implementation - Swift is =
capable by way of overloading operators (at least last I used it). =
Definitely would like more examples of languages that do something like =
this. (Links to those conversations to glean high-level concerns and =
possible problems might be helpful as well.)

Definitely not looking to pursue both at this time as emptiness or =
nonzero is harder for me to justify to myself, much less the larger =
community - not that it shouldn=E2=80=99t happen.

Cheers,
Johs


--Apple-Mail=_8CE391CA-A49D-48F7-852A-27E4A7AFB5F4--