Thank you all for the engagement so far. (Note: All scalar types and one compound type can be cast as true or false natively - of the scalar and compound types, callable and object are the only two with no, native false representation.)
> Have you tried not initializing invalid objects? This could help you. Also > that sounds more logical to me as I don't see any reasons to initialize > invalid objects if it's a matter of simple validation instead. I've tried valid objects (multiple approaches) - and I’m using the term valid loosely because the instances are not, technically, invalid in the strictest sense. I’m using “valid” and “invalid” as method names in the implementation because I don’t have a better word to describe the concept; still looking. If you'd like to hear more, please let me know and I can detail out other approaches, which are pretty standard. I only used it as an example of what would be possible and trying to illustrate using a real world example of the problem-space. With that said, the RFC isn’t meant to directly solve an implementation issue that can’t be solved any other way; it’s more syntax, style, and consistency (see note above). Similar to: function x(?SomeType $arg): ?SomeOtherType Instead of: function x(SomeType|null $arg): SomeType|null Both are the same thing under the hood. In that same spirit, totally opt-in - not required to use or you can get there some other way - similar to Marco’s comment around __toString. For example, I actively avoid null and don’t use most null-related things available in PHP and tend to wrap objects, methods, and functions that might return null…but, if you’re into null, don’t let me stop you. :) (I also tend to wrap objects, methods, and functions that return bool and some other type to put them in a context where I get one or the other, but not either-or - file_put_contents, for example…big fan of single return types.) > The one situation in which I can think of where an object might legitimately > have a falsey bool casting is if it represents a single value I see that, though I don’t necessarily agree. To use similar language, the object could represent a single, complex concept (especially through composition) - not just a single value. A car without a blinker is still a car and usable for most things it was designed for - and there could be a fallback for the missing blinker; valid instance with a non-blocking deficiency: https://www.dmv.org/how-to-guides/hand-signals-guide.php >>> P.S. I don't see it feasible to have objects that evaluate false in logical >>> expressions. I’m interested in more detail on this. Feasible as in not possible to do easily? Not possible in general? Or, something else? > For better or for worse (IMHO, for worse), `SimpleXMLElement` instances > representing attributeless empty elements are already falsy, so yes, it is > absolutely feasible. Interesting use case. Haven’t used SimpleXMLElement enough to comment. Interested to hear more. > This is absolutely terrifying. Not sure if this is referring to the SimpleXMLElement reference or beyond it. :) Cheers, Josh > On Nov 2, 2022, at 2:09 PM, Marco Pivetta <ocram...@gmail.com> wrote: > > On Wed, 2 Nov 2022 at 18:51, Claude Pache <claude.pa...@gmail.com> wrote: > >> >> >>> Le 2 nov. 2022 à 09:12, Michał Marcin Brzuchalski < >> michal.brzuchal...@gmail.com> a écrit : >>> >>> P.S. I don't see it feasible to have objects that evaluate false in >>> logical expressions. >> >> For better or for worse (IMHO, for worse), `SimpleXMLElement` instances >> representing attributeless empty elements are already falsy, so yes, it is >> absolutely feasible. >> >> —Claude > > > This is absolutely terrifying. > > Marco Pivetta > > https://twitter.com/Ocramius > > https://ocramius.github.io/
