[CONCEPT][DISCUSSION] Instance as boolean

Hello Josh,

Link to working draft: https://bit.ly/php-0001 https://bit.ly/php-0001

From a type safety POV I'd prefer to have an interface available, the
same way we did
to the Stringable interface RFC. But I'd rather keep these engine
affecting behaviors
with the same magic method naming conventions and its __ prefix.

So implements Bool + function __toBool() : bool is the only path that seems
entirely consistent with what we already have.

The draft doesn't mention (bool) casting behavior at the time I'm
reading it, but you do
mention the possibility. It seems necessary to me. Why wouldn't
(bool) $my_bool_obj
behave differently from (string) $my_stringable_obj?

ps. If you have any feedback or information on social interactions here that might help, please do let me know, normally I would have watched for a while before putting my foot in - hopefully it doesn’t end up in my mouth. :)

Thanks,
Márcio Almada

Link to working draft: https://bit.ly/php-0001 https://bit.ly/php-0001

Discussion on implementing a means by which a class instance can
interacted with syntactically as a boolean.

At this point in the discuss the only means discussed is creation of a
method (magic or via an interface).

Ability to cast is not ruled out.

And, my limited knowledge of PHP at this depth, much less under the
hood, means there could be a lot of unknown unknowns regarding the ways
a boolean can be interpreted and interacted with; therefore, those may
not be covered at this time.

I’m also not liking the overly contrived nature of the samples and will
improve those over time should interest maintain or increase.

Cheers,
Josh

ps. If you have any feedback or information on social interactions here
that might help, please do let me know, normally I would have watched
for a while before putting my foot in - hopefully it doesn’t end up in
my mouth. :)

Hi Josh.

Your social interactions seem fine, no worries. :-) You may need to ask for wiki access; the configuration/rules around it are, honestly, kinda weird.

To the RFC itself, as you've likely noticed you've stumbled into a long-running contentious question. __toString() is itself already controversial and some don't like it, while others want to see every possible primitive type added for completeness.

Focusing on Bool is, I think, a good choice because it has an argument for it other than "well it works for strings." You hint at it in the writeup but really bury the lead: Null objects.

Being able to not use null or false as a "not found" case and instead return an "empty" value object is very nice, but then you also want to know if the value returned is legitimate. An object that could self-cast to boolean makes something like this viable and type-safe:

$user = $repo->getUserById(5);
if ($user) {
// Do stuff with user
}
else {
// The user wasn't found.
}

No exception needed, no null, no false, just a safe "empty" user object; whether you want to branch the logic based on that is then up to the caller. It also allows an "empty" object to still have default values inside it (like a username of "Anonymous" or something), which are up to the implementer.

I'd say focus on that benefit. The similarity to __toString() is just to show that the implementation is consistent with existing patterns, not an argument for adding _toBool() itself. Feel free to steal the user-repo example if you want.

I have no strong feelings about interface vs. magic method, that's an old race I don't have a horse in.

--Larry Garfield