Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104277
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>
 <CAG9XoMQt8xNdm3mPUMfJ00ZJHB4UN_j1-uoQTVMMBSKzWW3f_w@mail.gmail.com> <d5476721-ead7-11fb-9949-0a9422cd64a1@gmail.com>
In-Reply-To: <d5476721-ead7-11fb-9949-0a9422cd64a1@gmail.com>
Date: Thu, 7 Feb 2019 10:35:40 +0100
Message-ID: <CAG9XoMRwREEvwbDrayvTTQMYWKkX1khnj+_2h2qMDDC=4V7G5A@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000085605005814a912a"
Subject: Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000085605005814a912a
Content-Type: text/plain; charset="UTF-8"

>
> apologies if I've missed it, but have you actually said what that use case
> is?


Sorry if it wasn't clear in my original post. The use case is the following:

- a data mapper retrieves an object from the database
- for optimization purposes, we can ask the data mapper to return a partial
object, with only a handful of properties initialized
- when saving the (potentially partial) entity to the database, the data
mapper needs to read initialized properties only

So this would require to be able to quickly (faster than reflection) detect
if a property is initialized before attempting to read it.

To summarize what's been said so far (provided that my understanding is
correct, as I haven't received additional feedback from Nikita yet):

- an additional language construct similar to isset(), but returning true
for null values, would not be particularly welcome
- an additional function such as property_is_initialized() could do the job

Note that I don't want to be pushy for an additional opcode for
property_is_initialized(), this can be discussed later if benchmarks
justify it. For now, just adding this additional function should be enough
to bring at least a 2x performance improvement over reflection when reading
all *initialized *properties from an object (benchmarked using a no-op
function that always returns true).

Ben



On Wed, 6 Feb 2019 at 23:21, Rowan Collins <rowan.collins@gmail.com> wrote:

> On 06/02/2019 22:10, Benjamin Morel wrote:
> > 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?
>
> I apologise for the digression. However, there is some relevance,
> because asking for not just a new function, but a new opcode, suggests
> you have a use case that is both common and performance critical;
> apologies if I've missed it, but have you actually said what that use
> case is?
>
>
>  > Pardon my ignorance, but what is exactly increasing the language
> complexity? Do you mean the addition of a language construct to the parser?
>
> Notice that Nikita said "conceptual language complexity", not
> "implementation complexity" - regardless of how simple this is in
> implementation, it's one more thing to document, maintain, and answer
> questions about.
>
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>

--00000000000085605005814a912a--