On Wed, Jul 15, 2020, at 9:24 AM, David Rodrigues wrote:
> I really appreciate any effort that can make PHP a more powerful language.
> However, for this item, I believe it will generate much greater cognitive
> complexity for new users (and I hate to assume that this is a problem, but
> we have to remember our roots).
>
> Why, for now a variable $x will be truth, since it is an instance of an
> object, now it could be false, because it implements __toBool() and
> Falsiable interface in a "magic" way, making everything very confusing if
> the user is not aware of each class that he is instantiating (or even
> receiving from other places without much condition to know precisely what
> it is).
>
> For this type of situation, I still prefer the introduction of clearer
> methods that suggest the validation of your own properties, in order to
> make it much more flexible than simply returning a single "general" boolean
> by-instance. For example: isValid().
>
> if ($entity?->isAdministrator()) { /** Entity is an administrator. */ }
> else if ($entity?->isModerator()) { /** Entity is a moderator. */ }
> else if ($entity) { /** Entity should be an user or similar. */ }
> else { /** Entity is not defined. */ }
>
> On the other hand, the implicity (bool) cast working together with
> __toBool() is a good one, but I think that it is being discussed in another
> topic.
>
>
> Atenciosamente,
> David Rodrigues
This really isn't about using the variable that comes back. For that, sure,
nullsafe is helpful. It's about the type of the return value and allowing a
class to have an "empty"/"false"/"nope" version.
$u = $repo->getUser($id);
What happens if the user isn't found in the DB? Options today are:
1) return null, which is a non-type, and thus you need to make the return type
?User or User|null, which means the caller *must* always check it's nullness.
2) return false, which is just wrong on numerous levels and you should never do
that.
3) Throw an exception, which is expensive in PHP. Now you're using an
exception for flow control, which is generally disapproved of.
Allowing an object to falsify itself is a 4th, more type-safe option. It lets
you return an object that both fails a boolean check (like null) but also has
default values in it for the base case. A user object likely wouldn't use
that, but a value object like an Address very well could.
Until we can support for-reals monads (which would require enums and generics
to do properly; the former is possible the latter is very hard), it's the best
option we have for more type-safe returns.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
