Re: [RFC][Discussion] Objects can be declared falsifiable
| From: | Josh Bruce | Date: | Thu, 03 Nov 2022 01:51:16 +0000 |
| Subject: | Re: [RFC][Discussion] Objects can be declared falsifiable | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118947@lists.php.net to get a copy of this message | ||
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 <ocramius@gmail.com> wrote:
>
> On Wed, 2 Nov 2022 at 18:51, Claude Pache <claude.pache@gmail.com> wrote:
>
>>
>>
>>> Le 2 nov. 2022 à 09:12, Michał Marcin Brzuchalski <
>> michal.brzuchalski@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/