Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122185
MIME-Version: 1.0
References: <bcca1ceb3d205fb15251d6010f91d36c@xpple.dev> <6246AF4D-C204-443C-9056-F662E59AA687@sakiot.com>
 <CAOyH9yQc=kwA2yjf48S9NP9kFj2oCBnEQzYTTZE-T-mkh7687Q@mail.gmail.com>
In-Reply-To: <CAOyH9yQc=kwA2yjf48S9NP9kFj2oCBnEQzYTTZE-T-mkh7687Q@mail.gmail.com>
Date: Fri, 19 Jan 2024 10:47:12 +0100
Message-ID: <CANS-=pfj2F642ofQjBp4vrszt=DMEpvq-X4Uw_TnySNa-ic73g@mail.gmail.com>
To: Alexander Pravdin <alex.pravdin@interi.co>
Cc: Saki Takamachi <saki@sakiot.com>, php@xpple.dev, Niels Dossche <dossche.niels@gmail.com>, 
	internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d512c8060f495eb9"
Subject: Re: [PHP-DEV] `PDO::FETCH_CONSTRUCTOR` fetch mode proposal
From: kjarli@gmail.com (Lynn)

--000000000000d512c8060f495eb9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 19, 2024 at 1:51=E2=80=AFAM Alexander Pravdin <alex.pravdin@int=
eri.co>
wrote:

> I would also suggest supporting readonly classes and creating special
> attributes to help map data fields to constructor arguments. Something li=
ke
> 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 defaul=
t
> value
>     );
> }
>
> --
> Best regards,
> Alex
>
>
> On Fri, Jan 19, 2024 at 9:05=E2=80=AFAM Saki Takamachi <saki@sakiot.com> =
wrote:
>
> > Hi Frederik
> >
> > > First off, please excuse me if I=E2=80=99ve done something wrong rela=
ted to the
> > usage of the mailing list. This all is completely new to me.
> >
> > Welcome to the internal mailing list! I had looked the pull request, an=
d
> > I'm pleased to have received your email promptly.
> >
> > > Thank you, the link was originally on the text "on GitHub" but it see=
ms
> > to have been stripped.
> >
> > Since mailing lists are text rather than HTML, you cannot attach links =
to
> > strings.
> >
> > > I hereby want to propose a new fetch mode for PDO. I=E2=80=99ve detai=
led the
> > motivation for it on GitHub. I haven=E2=80=99t actually written the cod=
e for it,
> > but it should not be too difficult.
> >
> > 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 approach,
> > but I think another option would be to give attributes to properties an=
d
> > 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 users=
.
> >
> > 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 even 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.

--000000000000d512c8060f495eb9--