Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122197
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1374-gc37f3abe3d-fm-20240102.001-gc37f3abe
MIME-Version: 1.0
Message-ID: <d0913897-97bc-41d1-9d45-2fe25e2ff375@app.fastmail.com>
In-Reply-To: 
 <CANS-=pfj2F642ofQjBp4vrszt=DMEpvq-X4Uw_TnySNa-ic73g@mail.gmail.com>
References: <bcca1ceb3d205fb15251d6010f91d36c@xpple.dev>
 <6246AF4D-C204-443C-9056-F662E59AA687@sakiot.com>
 <CAOyH9yQc=kwA2yjf48S9NP9kFj2oCBnEQzYTTZE-T-mkh7687Q@mail.gmail.com>
 <CANS-=pfj2F642ofQjBp4vrszt=DMEpvq-X4Uw_TnySNa-ic73g@mail.gmail.com>
Date: Fri, 19 Jan 2024 18:03:48 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] `PDO::FETCH_CONSTRUCTOR` fetch mode proposal
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jan 19, 2024, at 9:47 AM, Lynn wrote:
> On Fri, Jan 19, 2024 at 1:51=E2=80=AFAM Alexander Pravdin <alex.pravdi=
n@interi.co>
> wrote:
>
>> I would also suggest supporting readonly classes and creating special
>> attributes to help map data fields to constructor arguments. Somethin=
g like
>> this:
>>
>> readonly class User {
>>     public function  __construct(
>>         #[PDOField('user_id')]
>>         public string $userId,
>>         #[PDOField('user_name')]
>>         public string $userName,
>>         #[PDOField('user_address')]
>>         public ?string $userAddress =3D '', // Optional field with de=
fault
>> value
>>     );
>> }

*snip*

>> > Now, I agree that it is often not possible to use `PDO::FETCH_CLASS`
>> > because DB column names are typically snake case and variables and
>> > properties are camel case.
>> >
>> > IMHO, passing arguments to the constructor in order is a good appro=
ach,
>> > but I think another option would be to give attributes to propertie=
s and
>> > map data appropriately when using PDO::FETCH_CLASS.
>> >
>> > e.g.
>> > ```
>> > #[ColumnName('user_name')]
>> > private string $userName;
>> > ```
>> >
>> > In addition to the concerns mentioned in the pull request, I'm also
>> > concerned that more modes with similar functionality will confuse u=
sers.
>> >
>> > Regards.
>> >
>> > Saki
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: https://www.php.net/unsub.php
>> >
>> >
>>
>
> Would it be interesting to see if there's a way to make the hydration =
of
> objects more standard in PHP? PDO could then use that
> underlying implementation, but so could every existing library, or eve=
n PHP
> extension (SOAP/XML/JSON) that does anything related to object
> hydration/(de)serialization. I'm looking at Symfony, Doctrine, and all=
 the
> other serialization/hydration/auto-mapper library maintainers) for this
> because I wouldn't be able to design this myself.

Hi, maintainer of Crell/Serde here, as requested. :-)

I am highly skeptical that any serious standardization could happen in c=
ore directly.  Not because of incompatibility between existing libraries=
 really (we can adapt), but because the problem space is a lot more comp=
lex than it first seems, and that complexity means there's many valid bu=
t incompatible ways to go about it.

Just to use the name example, for Serde, I support a `serializedName` de=
claration on a given property, but also a `renameWith` declaration that =
specifies different rules for processing the name.  There's built-in opt=
ions like Prefix('some_string_'), case folding via enum objects (like Ca=
ses::snake_case), and you can put an arbitrary object on it as long as i=
t's all compile-time defined.  (Eg, you can do a suffix one if you want,=
 but I don't provide it.)  The `renameWith` directive can also be put on=
 the class level, and that will apply to all properties unless otherwise=
 specified.  Then I'm in the process of adding renaming capability that'=
s tied to when flattening nested objects.

And that's just for naming things.  How much of that should be standardi=
zed?  How much should PHP do itself, and how much is better left for eit=
her de-facto standardization or FIG?  If we do just a little bit (such a=
s a strict `#[SerializedName('some_string')]` attribute and nothing else=
), does that make it more difficult to do more complex things like I do?

Something like `#[SerializedName]` is probably safe enough to do that it=
 wouldn't cause problems, but then what does it actually do *in core* ra=
ther than just be a common name for Serde, Symfony, etc. to use?  Does s=
erialize() use it?  What then happens on unserialize()?  How does that i=
nteract with __serialize()/__unserialize()?

And that's *just* naming things.  That's before we even get into type ma=
pping, flattening, defaults, post-deserialize validation, and all the ot=
her stuff.

So it's possible we could do something here, but it will require a lot o=
f thought and care to not paint ourselves into a corner.

Regarding PDO hydration in particular, while a `#[SerializedName]` attri=
bute or similar seems nice, that immediately runs into a problem.  What =
if you want to use that object for populating from a DB, as well as for =
round-tripping from JSON?  Are you locked into the same name in both cas=
es?  If not, how do you differentiate them?  I have a solution for that =
in Serde, Symfony Serializer has something similar, but is that somethin=
g that we want to bake into core?  If not, does that mean we cannot supp=
ort multi-format serializing rules in the future?

Additionally, while we're talking mostly about names here, there's also =
the question of types.  Postgres, for instance, supports a much wider se=
t of column types than PDO.  For instance, it supports typed array colum=
ns (array of ints, array of strings, etc.).  PDO sees those as strings, =
which you need to then parse back out into something, and that parsing i=
s not trivial, because reasons.  So if doing a FETCH_CONSTRUCTOR approac=
h, would you need to accept a string in the constructor, then parse it t=
o an array in the body?  That precludes using CPP.  That's before we eve=
n get to custom types, which are sort of like object properties and woul=
d probably map to that.  But... Is that reasonable to built in by defaul=
t?  How, exactly?

All of which is to say that while I would love to make PDO better and th=
e serialization/deserialization story better, I think it's too complex t=
o be really *solved* in core.  If anything, we should focus on asking wh=
at would make it easier to build user-space wrappers *on* PDO that do th=
at more complex stuff (renaming, type translation, etc.) in user-space. =
 I'm not convinced that FETCH_CONSTRUCTOR would be a net improvement or =
if it would get in the way of that more complex stuff.  I could still be=
 convinced of it, though, if we can be reasonably confident that it does=
n't have unintended negative consequences to future design, the way read=
only did.

--Larry Garfield