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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
