Re: Re: [RFC] [VOTE] Typed properties v2
| From: | Rowan Collins | Date: | Thu, 07 Feb 2019 12:21:13 +0000 |
| Subject: | Re: Re: [RFC] [VOTE] Typed properties v2 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-104284@lists.php.net to get a copy of this message | ||
On Thu, 7 Feb 2019 at 11:08, Benjamin Morel <benjamin.morel@gmail.com>
wrote:
> Plus, as I stated earlier, I'm confident that typed properties will give
> much more credit to this approach, as we'll get an immediate Error should
> we accidentally access an uninitialized property, as opposed to a null
> value previously.
>
I don't think that solves the fundamental problem, which is that if a
partial object leaks into a wider application context, *correctly written*
code will misbehave. Code that previously ran safely suddenly throwing
exceptions is just as likely to cause serious bugs as code receiving
unexpected nulls, so all the caveats still apply.
>
> I can see that it would be elegant if this function existed, but it seems
>> a thin justification for adding it, when the whole problem could just be
>> approached a different way - e.g.add a property to the model called
>> $_partialFields that stores which fields were initialised.
>
>
> This breaks the separation of concerns: the model should only be concerned
> about business logic, and not contain any persistence-related fields.
>
I think you've already broken encapsulation by forcing the object to be
partial in the first place. Every piece of code interacting with this
object needs to know that it's given a partial, and handle it
appropriately, so it feels unnecessary to pretend that this is still just a
dumb data object to be persisted later.
Regards,
--
Rowan Collins
[IMSoP]