Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104281
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> <CAG9XoMRwREEvwbDrayvTTQMYWKkX1khnj+_2h2qMDDC=4V7G5A@mail.gmail.com>
 <CALKiJKoh7hCiJ_LTAzpzGubab5+pavdEFgzvtqDWT2r42Zda2g@mail.gmail.com> <CAG9XoMQDgW8QCGOdih_UpXC5C8ivOczuM3AN9LHPYLMVRAGANA@mail.gmail.com>
In-Reply-To: <CAG9XoMQDgW8QCGOdih_UpXC5C8ivOczuM3AN9LHPYLMVRAGANA@mail.gmail.com>
Date: Thu, 7 Feb 2019 11:18:05 +0000
Message-ID: <CADyq6s+bd09sykzc35-GjmrX1dj--Qb74n_f6DSw8BngiiY0dg@mail.gmail.com>
To: Benjamin Morel <benjamin.morel@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d30a8305814bffdc"
Subject: Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2
From: ocramius@gmail.com (Marco Pivetta)

--000000000000d30a8305814bffdc
Content-Type: text/plain; charset="UTF-8"

Hey Ben,

FWIW, I also worked on a similar feature via transparent proxying (never
finished though): it is an edge case that can be handled in userland, and
it doesn't need to be performance sensitive ("edge case"), since the
trade-off is more CPU vs less I/O and memory usage (skip loading of LOB
fields, for example).

This does not warrant special attention until it becomes very much a
bottleneck for execution.

You already have two different ways of achieving this:
 1. The reflection API added by this RFC
 2. `array_key_exists()` + `(array)` cast

Both of the above work well and are perfectly OK to use, considering what
partial loading is designed for (memory/IO usage reduction).

On Thu, 7 Feb 2019, 11:08 Benjamin Morel <benjamin.morel@gmail.com wrote:

> >
> > So this entire feature request is to support something which the Doctrine
> > manual spends several paragraphs saying you should probably never use?
>
>
> If Doctrine authors thought that you should *never *use it, they would
> never have added the feature in the first place. They just place a big
> caveat on top of it, that it's for specific optimizations, and that it may
> break your code; it's obvious that you should always start with full
> objects and optimize later, but these kind of optimizations can make a huge
> difference in a high traffic app, performing many small updates. Adding
> this small function may contribute to writing a very fast data mapper, that
> could allow us to use objects where we would have typically reverted to
> plain PDO for maximum throughput in specific cases, which makes a huge
> difference in code quality and maintainability if you ask me.
>
> 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 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. You
> could argue that this property could be created dynamically on the object
> by the data mapper, but then the mapper would have no way to determine if
> another property, that was not part of the loaded properties, has been
> initialized between the load() and save() calls. So back to square one, we
> need to be able to quickly determine which properties are initialized at
> any given time.
>
> Ben
>
>
>
>
> On Thu, 7 Feb 2019 at 11:42, Rowan Collins <rowan.collins@gmail.com>
> wrote:
>
> > On Thu, 7 Feb 2019 at 09:35, Benjamin Morel <benjamin.morel@gmail.com>
> > wrote:
> >
> >> 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 entire feature request is to support something which the Doctrine
> > manual spends several paragraphs saying you should probably never use?
> >
> > 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.
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
>

--000000000000d30a8305814bffdc--