Re: [RFC][Discussion] Objects can be declared falsifiable

> On Jul 16, 2020, at 10:28 AM, Josh Bruce <josh@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