Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110091
User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1
Mime-Version: 1.0
Message-ID: <a23cbbb0-bef4-4902-a7b6-b659ae9de5b7@www.fastmail.com>
In-Reply-To: <d0d91368-92ec-3f00-dd22-faed08b0ccf4@gmail.com>
References: 
 <CAF+90c8tW27-rhrk8pLieMsEWa4WHEBciPX1zThME68zf6s2QQ@mail.gmail.com>
 <1C09C0A9-1DA4-4753-8E5A-A739D52DA0B3@newclarity.net>
 <54c5f8f0-1526-53df-0912-0b00e0e54bc3@gmail.com>
 <44B0AB58-2993-403F-B75C-124AB26B6875@newclarity.net>
 <CALKiJKoX+J2YD7Aqxut145f9dYka7XpykBZLdhcM5z-yX4PU4Q@mail.gmail.com>
 <CD7E6018-8678-4CBE-B5CD-F7C3E1925BD6@newclarity.net>
 <d0d91368-92ec-3f00-dd22-faed08b0ccf4@gmail.com>
Date: Fri, 08 May 2020 13:43:46 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Parameter_Blocks_(vs._Constructor_Property?=
 =?UTF-8?Q?_Promotion_and_Named_Parameters)?=
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 8, 2020, at 1:04 PM, Rowan Tommins wrote:
> On 08/05/2020 02:32, Mike Schinkel wrote:

> > 8. I believe this alternate syntax addresses Michal Bruzuchalski's and Larry Garfield's concerns...
> > 10. Nikita claims there is a "line" to be crossed when property declarations have their own blocks and would disallow their use with CPP...
> 
> 
> I hesitate to speak for them, but I think their concerns are more 
> conceptual: that this requires nesting a large portion of the class 
> definition inside the constructor definition. Changing the syntax 
> doesn't really change that - the "parameter block" would still be an 
> extra level of nesting, attached to the constructor definition, rather 
> than at the top level of the class, where it lives today.

Correct.  My concern isn't with comma vs semicolon.  My concern is that the property definition is then living between `public function __construct(` and `) {`.

When the property definition is basic (visibility, type, and something like readonly) that's still reasonable enough for the benefit it brings.

When the property definition becomes involved enough that it is preferable to have it span lines (docblock, attributes, or something like property accessors or potentially even just asymmetric visibility), that's when I get fidgety, because then you're technically writing

public function __construct(/** @see blah.html */ <<Positive>> protected int $count, /** @see blah.html */ <<Positive>> <<LessThan(99)>> protected int $age,) {

}

Just with convenience newlines.  Semi-colons and curly braces wouldn't in themselves address that.

What *might* would be putting promotable properties in an entirely separate construct from the constructor.

An off the cuff riff from that might be something like:

class Stuff {

  promoted {

    /**
      * @see blah.html 
      */
    <<Positive>>
    protected int $count;

    /**
      * @see blah.html 
      */
    <<Positive>>
    <<LessThan(99)>>
    protected int $age;
  }
}

That moves them out of the constructor entirely, and might overlap with the desire for named parameters.

$p = new Stuff(5, 30);
// or
$p = new Stuff{count: 5, age: 30};

However, that has the major drawback of then not being in the constructor, so promoting only some constructor arguments becomes impossible.  It's also worse on the BC front.

I don't know if that's a good idea or not; as I said, just an off-the-cuff riff on what would address the "complex properties" question better.  For the simple case, the current RFC syntax seems fine.  (Maybe someone can riff off of this to something better.)

--Larry Garfield