Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109256
User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1
Mime-Version: 1.0
Message-ID: <e84fcd53-3db9-44d0-84ab-364e1aba7d8d@www.fastmail.com>
In-Reply-To: 
 <CABdc3WqSo4RY2vNsTcGMZ9cVATH5FfK0sv0ePEOdRj1ENs4j7g@mail.gmail.com>
References: <1b781e1e-3f27-485b-ab47-5eeaf9496548@www.fastmail.com>
 <CAAKU0u=B5LwjVaSk9u_MAuHb+qzaxSqnWdtZqtFS4fsD6dejpQ@mail.gmail.com>
 <0af67f9d-ce2a-476f-abad-385080ce14e8@www.fastmail.com>
 <CABdc3WqSo4RY2vNsTcGMZ9cVATH5FfK0sv0ePEOdRj1ENs4j7g@mail.gmail.com>
Date: Mon, 23 Mar 2020 15:20:42 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Mar 23, 2020, at 2:47 PM, Micha=C5=82 Brzuchalski wrote:
> Hi Larry,

> > The value here is combining constructor promotion with named paramet=
ers.
> > Constructor promotion itself is useful for the class implementer, bu=
t
> > doesn't help the caller.  Named parameters helps the caller, but doe=
sn't
> > really help the class implementer.  The combination of both of them
> > together gives us something similar to the object-initializer syntax=
 as a
> > net result, but with many other benefits because it's not a one-off =
syntax.
> >
> > So with the two of them together, you get:
> >
> > class Point {
> >   public function __construct({public int $x, public int $y});
> > }
> >
> > Which then allows any of these construction mechanisms:
> >
> > $p1 =3D new Point(5, 7);
> > $p2 =3D new Point({x: 5, y: 7});
> > $p3 =3D new Point({y: 7, x: 5});
> >
> > All of which result in an object you can use the same way:
> >
> > print $p1->x . ', '.  $p1->y;
> >
> >
> I agree it looks a little bit awkward and differs from object-initiali=
zers
> known from other languages,
> but let's say it would work somehow for this example. Now make it not =
2 but
> 10-15 properties
> with real types sometimes quite long so after 3-5 of them you should b=
reak
> the line,
> then add some default values.
> Like a real entity which with typed properties doesn't need setters an=
d
> getters.
>=20
> The example grows but even when breaking a line after each
> parameter/property still could be somehow readable.
>=20
> Now as we deal with Entity add some annotations or let's go hype, try=20=

> with
> new Attributes v2
> proposed by Benjamin Eberlei
> https://wiki.php.net/rfc/attributes_v2#userland_use-casemigrating_doct=
rine_annotations_from_docblocks_to_attributes
> 3 for $id and for the rest at least one attribute per property.
>=20
> class Product {
>     public function __construct({
>         <<ORM\Id>>
>         <<ORM\Column>>
>         <<ORM\GeneratedValue>>
>         public int $id,
>=20
>         <<ORM\Column(["unique" =3D> true])>>
>         public string $name,
>=20
>         <<ORM\Column>>
>         public string $description
>     });
> }
>=20
> Let's stop on 3 I think it's enough to see it's:
> 1. unusual to see annotations in method signature declaration
> 2. not readable anymore.
>=20
> Now if you say it shouldn't be like that and all the properties should=
 be
> declared as normal properties,
> then the constructor is not needed to simplify the declaration but sti=
ll
> requires a lot of boilerplate on
> the caller side undoubtedly.
>=20
> Do you still think object-initializer is pointless and useless and can=
 be
> replaced with
> named arguments and constructor arguments promotion?
>=20
> Cheers,
> Micha=C5=82


Yes, I responded to the annotations point in my earlier reply.  I hadn't=
 considered those, so we'll likely need to consider alternate syntaxes i=
f we want both annotations and constructor promotion (which I do).  Howe=
ver, note that even the (admittedly fugly) Product example you have abov=
e, each property name is listed only once, not 4 times, making it still =
an improvement on the status quo as far as redundancy.

However, I still hold that constructor promotion and named parameters, t=
aken together, are strictly superior to a one-off syntax for objects tha=
t only supports public properties, as they offer more capabilities and h=
ave less potential to be confused with future additions. =20

Eg, object-initalizer syntax vs named parameters on a constructor; which=
 to use when?  Why?  Why do both exist?  They really shouldn't.  Named p=
arams would be better than object-initalizers all on their own, regardle=
ss of whether constructor promotion is included, precisely because they =
offer more capability for the same syntactic addition.

--Larry Garfield