On Wed, Jul 8, 2020, at 11:39 AM, Josh Bruce wrote:
> 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
