Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104280
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>
In-Reply-To: <CALKiJKoh7hCiJ_LTAzpzGubab5+pavdEFgzvtqDWT2r42Zda2g@mail.gmail.com>
Date: Thu, 7 Feb 2019 12:08:25 +0100
Message-ID: <CAG9XoMQDgW8QCGOdih_UpXC5C8ivOczuM3AN9LHPYLMVRAGANA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000036d12305814bddd5"
Subject: Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000036d12305814bddd5
Content-Type: text/plain; charset="UTF-8"

>
> 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]
>

--00000000000036d12305814bddd5--