Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110049
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAF+90c8tW27-rhrk8pLieMsEWa4WHEBciPX1zThME68zf6s2QQ@mail.gmail.com>
Date: Wed, 6 May 2020 15:48:50 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <1C09C0A9-1DA4-4753-8E5A-A739D52DA0B3@newclarity.net>
References: <CAF+90c8tW27-rhrk8pLieMsEWa4WHEBciPX1zThME68zf6s2QQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Parameter Blocks (vs. Constructor Property
 Promotion and Named Parameters)
From: mike@newclarity.net (Mike Schinkel)

> On Mar 26, 2020, at 9:30 AM, Nikita Popov <nikita.ppv@gmail.com> =
wrote:
>=20
> Hi internals,
>=20
> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion
>=20
> 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.
>=20
> The primary motivation for this feature is to close the currently =
rather
> wide gap between the use of ad-hoc array structures, and the use of
> well-defined and type-safe value objects. The latter is what we want =
people
> to use, but the former is, unfortunately, what is *easy* to use.
>=20
> Regards,
> Nikita

I am rather concerned about constructor promotion will result in some =
complex "single" lines of code that all must be syntactically correct =
for any of it to be syntactically correct.  It will make it more =
challenging to read and write code as we add attributes and PHP doc to =
properties.  And if we still have to deal with concern that parameter =
names that were previously never indented to become part of the API will =
be exposed as part of the API, with potential breakage when name =
changes.

Pondering these issues I think I have a very simple proposal that would =
address most (all?) of the concerns I am aware for both Constructor =
Property Promotion and Named Parameters. =20

Consider simply what we might call "Parameter Blocks."  Since PHP always =
expects a parentheses to follow the function or method name it should be =
possible to opt-in replace it with a brace-enclosed block of parameters =
instead since it would be unambiguous and this no conflict, and no need =
for new keywords. =20

The following illustrates how it my be used by repurposing an example =
from the RFC:

abstract class Node {
    public function __construct{
    	/**
    	 * @param Location|null =E2=80=94 The starting location for this =
abstract node
    	 */
        Location $startLoc =3D null;

        protected Location $startLoc =3D null;

    	/**
    	 * @param Location|null =E2=80=94 The ending location for this =
abstract node
    	 */
        protected Location $endLoc =3D null;
    } {}
}
=20
class ParamNode extends Node {
    public function __construct{
    	/**
    	 * @param string $name =E2=80=94 Names this Node.
    	 */
        public string $name;

    	/**
    	 * @param ExprNode|null $default =E2=80=94 Contains the =
expression this node represents=20
    	 */
        <<ORM\Entity("exprNode")>>
        public ExprNode $default =3D null;

    	/**
    	 * @param TypeNode|null $type =E2=80=94 Contains the type =
expected for this node's expression
    	 */
        <<ORM\Entity("typeNode")>>
        public TypeNode $type =3D null;

    	/**
    	 * @param bool $byRef =E2=80=94 True if this node is a =
reference, false otherwise
    	 */
        public bool $byRef =3D false;

    	/**
    	 * @param bool $byRef =E2=80=94 True if this node is variadic, =
false otherwise
    	 */
        public bool $variadic =3D false;

    	/**
    	 * @param Location|null =E2=80=94 The starting location for this =
node
    	 */
        Location $startLoc =3D null;

    	/**
    	 * @param Location|null =E2=80=94 The ending location for this =
node
    	 */
        Location $endLoc =3D null;
    } {
        parent::__construct($startLoc, $endLoc);
    }
}

Envision how that same code would have to be written if all as part of =
the single "line" contained within the parenthesis of a programming =
language? =20

As far as I can tell this is a clean and elegant approach with many =
fewer downsides than those that have been discussed thus far.  I hope =
that each of you reading this will seriously consider this is viable =
alternative option.

-Mike