Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124480
Precedence: bulk
MIME-Version: 1.0
References: <CABY-Mhz36WtLx_1bWAmK8rUpqAQTEw3H1mziPa5TH4nEgeHYFg@mail.gmail.com>
 <CANLbj-pk9FmHKG+PZcK-ua1DGKbHJ6wtsCKedKJdMSJZdM+aPw@mail.gmail.com>
 <CAPPUTHo-pfQNK_CKGTMm8fj1=VJaLvk5Y2iRpbCewuNBY48sSw@mail.gmail.com>
 <CABY-Mhz5P+QgoTgfHd1RV2=U_YV7VT0Yn08C9E98DNr93+9w1g@mail.gmail.com> <f1b87815-6c72-45fb-8762-8f00ebfe8d90@app.fastmail.com>
In-Reply-To: <f1b87815-6c72-45fb-8762-8f00ebfe8d90@app.fastmail.com>
Reply-To: lilybergonzat+php@gmail.com
Date: Thu, 18 Jul 2024 16:03:36 +0200
Message-ID: <CAPPUTHo5g6gd=ZpYjEzXsRt1OYDs1zvxunWR115N1mOnh23ULw@mail.gmail.com>
Subject: Re: [PHP-DEV] Optional constructor body
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: lilybergonzat+php@gmail.com (Lily Bergonzat)

I would love to see those improvements as well, however I am surprised
we seem to be more inclined to push a more substantial change than a
minor one.

I feel like the more substantial one would be more likely to break
stuff, compared to the minor one, and so I don't see why the minor one
would be refused?

That said, I am new here, and I do not yet know how things work, so it
probably is because I lack experience.

On Thu, Jul 18, 2024 at 3:50=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com> wrote:
>
> On Thu, Jul 18, 2024, at 10:11 AM, Oliver Nybroe wrote:
> > Thanks for sharing previous discussions, I will definitely take a look
> > at those before writing up the RFC.
> >
> >
> >> If you do with to go with an RFC, I'd like to see if your proposal
> > addresses whether this syntax should implicitly call
> > `parent::__construct()`, and if a semi colon is expected or not
> > (`public function __construct(public int $foo);` vs `public function
> > __construct(public int $foo)`).
> > Thank you, these are very valuable points to address in the RFC.
> >
> > I can definitely feel that there will be some mixed opinions about
> > semicolon vs no semi colon.
> >
> >
> > Best regards
> > Oliver Nybroe (he/him)
>
> Please don't top-post.
>
> Since the last time this came up, PSR-12 has been replaced with PER-CS, w=
hich as of 2.0 now says:
>
> > If a function or method contains no statements or comments (such as an =
empty no-op implementation or when using constructor property promotion), t=
hen the body SHOULD be abbreviated as {} and placed on the same line as the=
 previous symbol, separated by a space.
>
> cf: https://www.php-fig.org/per/coding-style/#44-methods-and-functions
>
> (I... suppose technically it doesn't mention classes, but I've been doing=
 it for empty classes too.)
>
> So the "coding style" part of the previous issue has been resolved.  Whet=
her that changes anyone's mind about whether this should be done or not is =
up to them to decide.
>
> Personally, I'd probably vote for it if it came up, but I agree it's a pr=
etty minor improvement and unlikely to pass.  It would probably only be wor=
th doing if there were other common-pattern-optimizations around the constr=
uctor that came with it.  Things like auto-forwarding to the parent, or a m=
ore compact syntax than a full constructor method, or other things that mak=
e writing a "pure data" product type easier rather than just s/{}/;/
>
> I don't know what those could look like.  As a data point, in Kotlin (whi=
ch is what my day job is now), constructor properties are always promoted, =
essentially.
>
> class Foo(val a: String, val b: String) { // This is the equivalent of PH=
P's promoted properties.
>
>   val c: Int =3D 5 // A non-constructor-initialized property. These can h=
ave hooks, constructor ones I think cannot.
>
>   init {
>     // This is the non-promoted part of a constructor body, and runs afte=
r the properties are assigned.
>   }
> }
>
> In case of inheritance, there's dedicated required syntax for forwarding =
to the parent:
>
>
> class Foo(val a: String, val b: String) : Bar(b) { // equivalent to paren=
t::__construct($b)
>
> }
>
> You can also make the constructor private (etc.) with more explicitness:
>
> class Foo private constructor(val a: String, val b: String) {}
>
> Of note, if there's no constructor then the parens are omitted, and if th=
ere's no body then the {} body is omitted.  That means a great many "value =
objects"/DTOs, etc just look like this:
>
> class Foo(
>   val a: String,
>   val b: String,
> )
>
> Which would be equivalent to PHP's
>
> class Foo {
>   public function __construct(
>     public readonly string $a,
>     public readonly string $b.
>   ) {}
> }
>
> cf: https://kotlinlang.org/docs/classes.html
>
> To be clear, I'm not suggesting PHP just copy Kotlin directly.  I'm sayin=
g that if we want to improve the constructor syntax for common cases, which=
 I am open to, we should be looking to do something more substantial and er=
gonomic than just replacing {} with ;, and we could probably get some good =
inspiration from other languages in our family.  (Java, Kotlin, C#, Swift, =
etc.)
>
> --Larry Garfield