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’d prefer something else - still learning the Roman-way. :)
To Larry’s user example.
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 “"
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.
The only interaction on null that seems to fail outright (from personal
experience) is trying to call a method because it’s not an object. (It doesn’t
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’m thinking right now, for me, it’s 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.
> (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??
If email and within the last week or so, it might be this same conversation.
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:
>
> if (!$foo) {
> $foo->bar();
> }
Matthew: I can see that feeling like a bug, for me it would be a feature (can’t
believe I just said that).
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’t have the muscle memory for try-catch-throw and implementing errors).
I can’t 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’t.
My contract with a function call becomes: You will always get something of this
type - period. Whether it’s 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. "
>
> 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’t know of a way to add an interface to `new stdClass()` - but thought
this might be a valid use case:
$object = new \stdClass();
$object->__toBool = function() {
return false|true;
};
if (! $object) {
// made it
}
> "(Including __construct() replacing old style constructors in PHP 7.)" -
> __construct replaced old-style constructors in PHP 5. :-)
Here’s 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!
Not sure I’m getting the same issue. If you mean the line that starts with “row
1” - 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’t 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’t know anything about Java’s 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.
Marcio: Thanks for the example! I’ve 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’t happen.
Cheers,
Johs
