Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104262
MIME-Version: 1.0
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com>
 <CAF+90c_vvEUYE8_bgPVL0MTJeXik6fYsiueZo644OyZubj74jQ@mail.gmail.com>
 <595b374c-bc4f-9b8a-0013-6485abbfb477@php.net> <CAF+90c8FCMtwRoJEUjBg4XPumzUGFjh0nJa82MFpFFS+WB=rxA@mail.gmail.com>
 <CAG9XoMS2q4uttDpNHPDqSLB78YK1bnS9m7qQE9oTqteGUhTAbA@mail.gmail.com>
 <CALKiJKq9geVL9tLdduPpvGVmT9D8utrQN8oLYy_jqg8hSRhRRw@mail.gmail.com>
 <41D0A782-E4E2-4B98-9C5D-174143DE9A76@gmail.com> <CAG9XoMQY7J6ykjznuAOv06rKR0mDM-JX-dKYLFOt3EnBv3+X3A@mail.gmail.com>
 <CALKiJKpWBFhcbY3CEmykWVgEu0atOfQnV4VbQHzG0MFgG5=qqw@mail.gmail.com>
In-Reply-To: <CALKiJKpWBFhcbY3CEmykWVgEu0atOfQnV4VbQHzG0MFgG5=qqw@mail.gmail.com>
Date: Wed, 6 Feb 2019 23:10:06 +0100
Message-ID: <CAG9XoMQt8xNdm3mPUMfJ00ZJHB4UN_j1-uoQTVMMBSKzWW3f_w@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c75192058140fd3c"
Subject: Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2
From: benjamin.morel@gmail.com (Benjamin Morel)

--000000000000c75192058140fd3c
Content-Type: text/plain; charset="UTF-8"

I agree that what you say conceptually makes sense; however, in a pragmatic
world we usually deal with a single User class, and at some point we might
want to optimize a script that was accepting a User object, but was only
using, say its id and name. Doctrine already allows this, with a caveat:
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/partial-objects.html

You usually know where you loaded your User anyway; plus, it will still be
easier to debug an uninitialized property Error that will occur straight
away, rather than a null reference that can be passed along before erroring
somewhere else.

But we digress, can we focus on whether to add another isset()-like
construct, or a property_is_initialized() function, ideally with a
companion opcode to speed it up?

Thank you,
Ben

On Wed, 6 Feb 2019 at 18:38, Rowan Collins <rowan.collins@gmail.com> wrote:

> 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]
>

--000000000000c75192058140fd3c--