> On Jul 16, 2020, at 10:28 AM, Josh Bruce <j...@joshbruce.dev> wrote: > > 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 >
Apologies: I was NOT in the conversations leading up to null -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
