Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120031
MIME-Version: 1.0
References: <8a9a04b3-45e6-47dd-dee8-0f524e49bd37@gmail.com>
 <CAOWwgpnPxDg0VWCtwn9ALAdiHNn1SFjLAsvVJiMaR-QQc0fU2A@mail.gmail.com>
 <CALKiJKrCXgWmBzWB_HfcqbrA8G4xLDzdryOkcy+JjUCWm4fC5Q@mail.gmail.com>
 <CAOWwgpmOFek0oZt9aOg44nCbcbcY7J3T-Ghw=UvFFd6Ugr=pRA@mail.gmail.com>
 <c17185c0-9bbb-43be-9127-6dfc5ea6e33d@gmail.com> <c694900b-5f0d-493f-a454-9d51acd09ac4@app.fastmail.com>
 <52a5a80d-f03f-5e96-4188-272a705e3fdd@gmail.com> <b366ccc1-cb3a-4f1d-9f90-dc7043cbb588@app.fastmail.com>
 <CAOWwgpmudjArTFMxUsYL_1SDT+yEQAYKRa-6MTUqOUxxi0sa=g@mail.gmail.com>
In-Reply-To: <CAOWwgpmudjArTFMxUsYL_1SDT+yEQAYKRa-6MTUqOUxxi0sa=g@mail.gmail.com>
Date: Thu, 13 Apr 2023 16:19:47 +0100
Message-ID: <CALKiJKoFUALT+fzjbYV5aaeu2ED6Tayn3QO021dqwPwjEh2hqw@mail.gmail.com>
To: php internals <internals@lists.php.net>, Nicolas Grekas <nicolas.grekas+php@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000007446905f9394251"
Subject: Re: [PHP-DEV] Brainstorming idea: inline syntax for lexical
 (captured) variables
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000007446905f9394251
Content-Type: text/plain; charset="UTF-8"

On Thu, 13 Apr 2023 at 13:40, Nicolas Grekas <nicolas.grekas+php@gmail.com>
wrote:

>
> I created this draft RFC to help move things forward:
>
> https://wiki.php.net/rfc/syntax-to-capture-variables-when-declaring-anonymous-classes
>
> Please let me know your early thoughts and I'd be happy to move it to
> "under discussion".
> I'd also need someone for the implementation as I doubt I'll be able to
> write it myself in a reasonable time!
>


Hi Nicolas!

Thanks, it's really encouraging to have some interest in the feature.

The good news is that I have an implementation of this nearly ready (it
passes all my tests, but the code's a bit messy). I was hoping to polish it
over the Easter weekend and draft a PR, but wasn't feeling very well.

It has full support for visibility, types, references, and property
renaming, but no merging of parameter lists or automatic call to the parent
constructor. I think with clean errors that's a good first feature set, and
if someone comes up with an implementation for manipulating existing
constructors, that can be proposed later.

So, "watch this space", as the saying goes :)

Regards,
-- 
Rowan Tommins
[IMSoP]

--00000000000007446905f9394251--