Re: Re: [RFC] [VOTE] Typed properties v2
| From: | Rowan Collins | Date: | Wed, 06 Feb 2019 17:38:01 +0000 |
| Subject: | Re: Re: [RFC] [VOTE] Typed properties v2 | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-104257@lists.php.net to get a copy of this message | ||
On Wed, 6 Feb 2019 at 15:21, Benjamin Morel <benjamin.morel@gmail.com>
wrote:
> You're right, in most of the cases properties SHOULD be set by the
> constructor. I do find the current behaviour interesting, however, from a
> data mapper point of view: you might want to retrieve a partial object from
> the database, and get an Error if you accidentally access an uninitialized
> property, as opposed to the pre-typed properties era, where you would get
> null and the "error" would be silenced.
>
The problem with that is, the code doing the partial loading might be
thousands of lines from the code "accidentally" accessing the property. If,
for example, a User class supported partial loading of this sort, any
function that takes a User would have to handle the possibility that what
was actually passed was a partial User. If an error was raised, it would
require tracing back through the code to work out where the conversion from
partial to full object should have happened.
A cleaner implementation would have PartialUser as a different type, which
could not be passed to a function expecting a User; it would then be clear
that a specific code needed to perform a conversion to fetch the rest of
the data, e.g. function getUserFromPartial(PartialUser $partial): User
In other words, if the definition of User includes a non-nullable property
$name, then any object that doesn't have a value for $name is not actually
a User object.
Regards,
--
Rowan Collins
[IMSoP]