Re: [CONCEPT][DISCUSSION] Allow objects to declare emptiness and by extension truthiness

On Sun, Jul 12, 2020 at 7:49 PM Josh Bruce <josh@joshbruce.dev> wrote: > Latest version as we zero in on what this is really about: > https://bit.ly/php-0002 > <https://bit.ly/php-0002> > > Other threads: > > 1. https://externals.io/message/110879 < > https://externals.io/message/110879> > 2. https://externals.io/message/110881 < > https://externals.io/message/110881> > > Thanks for all the feedback so far! Definitely feels like progress. I have a really hard time understanding what is actually being proposed here. You mention the introduction of the Emptiable interface, but not how it influences empty() or (bool) casts. There's some examples in "Usage" that are possibly intended to illustrate this -- I suspect that a "return true" vs "return false" mixup has made them impossible to understand though. Some thoughts on the general domain: 1. I don't like the idea of decoupling empty() and (bool). empty($x) is currently the same as !$x (modulo notices), and changing that will make PHP's already messy implicit type conversion matrix even messier. 2. Coupling boolean casts to an "emptiness" concept seems somewhat dubious to me. That works for container structures, but what about something like new Bigint(0)? It would be quite odd to declare an integer "empty" to make it evaluate to false. 3. I'm generally not a fan of overloadable bool casts. We have exactly one object with an overloaded bool cast in PHP, and that's SimpleXMLElement. As far as I know, this has only caused issues. A big reason for that is that using "if ($foo->bar)" is a common idiom for checking "if ($foo->bar !== null)" -- one that works very reliably, with the exception of SimpleXMLElement. 4. I think if ($container->isEmpty()) is much clearer than if ($container) -- why would we want people to use the latter instead? Regards, Nikita