> > Latest version as we zero in on what this is really about: > https://bit.ly/php-0002 <https://bit.ly/php-0002> <https://bit.ly/php-0002 > <https://bit.ly/php-0002>> > > 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. >
Thanks for the feedback! Not all incorporated in the latest, due to timing: https://bit.ly/php-0002 Initially this started as a desire to be able to declare an object casting to bool (__toBool or something). After a couple rounds the relationship between empty() and bool surfaced. The question I’m volleying there is are they different concepts (a non-answer compared to a lie) and does it matter given the established norm. (Sounds like you’re in the established norm camp - I tend to lean that way as well.) > 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. This seems counter to the first bullet point. They already are coupled. The result of empty() tends to be the opposite of casting bool - unless there’s an example I’m unaware of. > > 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. I wasn’t aware of this. Thank you! I will take a look and see what problems people are running into and how it’s implemented - at least from a developer perspective. > 4. I think if ($container->isEmpty()) is much clearer than if ($container) -- > why would we want people to use the latter instead? Fair question. This made me raise the question in the draft and I’ll raise it here…under what circumstances would PHP return null from new. $instance = new MyClass(); If ($instance->isEmpty()) {} $inner = $instance->innerObject(); If ($innnerObject->isEmpty()) {} If I implement the innerObject() method to return null - and it does - then that call fails, because it’s null, which brings up your earlier point, I think. If ($innerObject) { // not null If ($innerObject->isEmpty()) { // two-step process with null-check } } // with the language feature If ($innerObject) { // I know it can give and receive messages, and is not empty } else { // I know it can give and receive messages, but is empty } I remember hearing what sounds like hyperbole but it said something like 40% of code written is guarding against null. I can totally see that being real so didn’t look much further into it. If we can guarantee that an object is that type of object - just happens to be empty, maybe we reduce or remove the need null-checks?? Cheers, Josh
