Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109343
MIME-Version: 1.0
References: <CAF+90c8tW27-rhrk8pLieMsEWa4WHEBciPX1zThME68zf6s2QQ@mail.gmail.com>
In-Reply-To: <CAF+90c8tW27-rhrk8pLieMsEWa4WHEBciPX1zThME68zf6s2QQ@mail.gmail.com>
Date: Thu, 26 Mar 2020 17:56:10 +0100
Message-ID: <CABdc3WqeyLQoJdbEeERn3pcZi9K+O8DBFgKo_01-wXDBVtwTwQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004d053a05a1c4dd3c"
Subject: Re: [PHP-DEV] [RFC] Constructor Property Promotion
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--0000000000004d053a05a1c4dd3c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

czw., 26 mar 2020 o 14:31 Nikita Popov <nikita.ppv@gmail.com> napisa=C5=82(=
a):

> Hi internals,
>
> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion
>
> This is based on one off the suggestions made in
> https://externals.io/message/109220, and some existing discussion on the
> topic can be found in that thread.
>
>
As I already said in linked topic. IMHO this is wrong and can be easily
overused.

A list of properties is changed into a list of constructor method arguments
which
can be easily overused on long argument lists and when the time comes to
have attributes then the list of promoted arguments with their annotations
and some extra blank lines then to improve readability could lead to
long constructor signature list on a different level of indentation which
also then always has to be un-collapsed in IDE and on the top of a class to
keep the track of properties where usually list of properties exists with
additional named constructors (always at the top).

Not even mentioning that mix of promoted and un-promoted argument list
would just feel awkward and that kind of mixed constructor where some of
arguments are assigned magically and some of them not can make it harder to
read.

And I'm not saying this cause I'm preparing another proposal for filling
the gap
between the use of ad-hoc array structures, and the use of well-defined and
type-safe value types.
I'm saying this because PHP was always verbose and easy to read/decipher
this solution IMHO has more drawbacks regarding readability than benefits.

Cheers,
--
Micha=C5=82 Brzuchalski

--0000000000004d053a05a1c4dd3c--