Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124470 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id EAB141A00B7 for ; Thu, 18 Jul 2024 10:11:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1721297606; bh=3yv/JorYAW5b3sOPYnjX2VzAmpIlqJkWXXczxmu5YR8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=A0a4pOo/OxcKQqSHtPyEtazXIGyWqTJS7ALplC+tj10mh1NKRD8HyVTcMkveM7vyH ONuy39Sfr7Az895u3vszbyZl6VyoZIX6tbvRwWEteBvPhYnzgl4o1wlvNIaw3s2K2t VhsF1kbQvI4VXGtzyUVcbXlkX8qngLNcgnlw4jAI3f6dXwMLdkQbTFrh1x+kpBWptR asG9yZNi6IWVpgvnaG3dVkb23uKS91S7qzy+nBJ4C9M2mvHV+s1ZcODmR7ZS8UlA0k y16uega1C26qU/R8vKytXOG6doAe0qyWbFf5kG4tg50ro3mmbMfjY2FOkpZfOl8QUt W0aGgj63Cb2lQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5E0A01804DE for ; Thu, 18 Jul 2024 10:13:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 18 Jul 2024 10:13:24 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-e03caab48a2so446417276.1 for ; Thu, 18 Jul 2024 03:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721297513; x=1721902313; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RfwLvU06m3gwdaOH8J7APydtn6328chVlqJcyzrmXX4=; b=cOl0LlQn6b/v4mPckhVrudiWLPQQPzVtdoEYlErK1SLGdUwrxqAHSjUu1R+ZDy/gij u6VK+1t4LoSi0xKqE5Byxfhm+kG4twBdeeQbFNq4s0PQVbWsndoB9vmoYNwqazk3D/bK +QW8X6Q+OstDt7tZe2DJc5zAe6SULHD/qKORZn6G5x3Z+8+gpBduwnPP//8fCYLZykky QsnWJHOUX2YWKlsHSWGfLXY6BewjaNP9l53ktMo7OSFFKLKS8hHa3FysvSpR8IHcwa6X PmqqWHsilMoshL5zioPT62oVfJNLW9jxaN3LZWqfxT5QD0eAdamsspaX8kFvdubzD+Ld MjHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721297513; x=1721902313; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RfwLvU06m3gwdaOH8J7APydtn6328chVlqJcyzrmXX4=; b=xMj09YMw0fmUlOCcb90AFykzIK0jaOsWYnUCmUzDjZ4gVc4EZmD5SgKUCy6MUZ6jTB Sm7cv1ckeGJBVF1YoCNNdK+q2cxjBlG6qxe4pvAmKLAE/i3ZUmb6kj6H8HgjkiwqEZ5Z 7rSma18NurRpX05IHT6uSoU7TxSnh9NTsFJz3zAmFPqv49py2TjMPmjJV384Y6IWxNoD m9chPBAhOermr8zl3ktJKC0QBAmdO3wno2mGvAblhBcsOradka+a4FQu+sy2YUZDHB04 Raau2M4nyilISszmcV84SNmu6U+9sOd5Fq43UdLKticz3jMBiMkBTnh9E5Z+szz3tqAa oYkQ== X-Forwarded-Encrypted: i=1; AJvYcCUQEHxNmtrHxe6kxRi8MT4bg77uog1VZVLoTv5eXcNIF9kFQmnZ/lpQ1te9sdq+a06rgEGo5jWTQ5a6ZqqSgU1oytDs1NkrdQ== X-Gm-Message-State: AOJu0YxHOAnymgzdVM5/Qh+qtHHTq39XoyDnTRR88j9pkGCm7Rbts6Wl Ck6+HOSxxe4kiWTYrRYdwa/xmBBEoPIJqBEngCAdysjTOCBRd0jXsGJ9c0RI5qs/DhKcGg4Kmu9 0aqHoxi6dKC99uEyjOqQy8CkML4k= X-Google-Smtp-Source: AGHT+IF+6Puieqztbw/sZmHCqzPfukq0eS5yRsmG05T1hTCcAv2wF+miapjNWFA0Cw10dzRHDw9GGpkSLiGDFZYNofM= X-Received: by 2002:a25:3:0:b0:e03:a923:8720 with SMTP id 3f1490d57ef6-e05fedb5f0fmr1423371276.0.1721297513549; Thu, 18 Jul 2024 03:11:53 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 18 Jul 2024 12:11:42 +0200 Message-ID: Subject: Re: [PHP-DEV] Optional constructor body To: lilybergonzat+php@gmail.com Cc: Ayesh Karunaratne , PHP internals Content-Type: multipart/alternative; boundary="000000000000d91b66061d82ce7e" From: olivernybroe@gmail.com (Oliver Nybroe) --000000000000d91b66061d82ce7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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) On Thu, 18 Jul 2024 at 11:49, Lily Bergonzat wrote: > I don't view this proposition as a breaking change. The way I > understand it, writing an empty body for a constructor would > still work, but we would also get the option to just omit the > body altogether. > > I think it would be a very sensible update. I also think it should > require a semicolon, just so we have the same kind of syntax > as interfaces. > > I would love to see such a change! > > On Thu, Jul 18, 2024 at 11:46=E2=80=AFAM Ayesh Karunaratne > wrote: > > > > > > > > Hello internals. > > > > > > I am looking into making the constructor body optional in classes, > essentially allowing you to write > > > > > > ``` > > > class User { > > > public function __construct( > > > private string $name, > > > ) > > > } > > > ``` > > > > > > Currently to make this code valid, it would have to be written the > following way > > > > > > ``` > > > class User { > > > public function __construct( > > > public string $name, > > > ) {} > > > } > > > ``` > > > > > > With the introduction or constructor property promotion in 8.0, we > often see classes where the constructor has an empty body, and my guess > would be that this will only increase with the introduction of property > access hooks in 8.4 which is allowed to be defined in the constructor als= o. > > > > > > This change would only be a cosmetic change and simplify the userland > code by removing two redundant characters. > > > > > > > > > > > > This would be my first RFC and I am willing to try and implement it > myself. > > > > > > > > > Best regards > > > Oliver Nybroe (he/him) > > > > Hi Oliver, > > > > Some links to previous discussions when this was brought up in the > > mailing list before: > > > > - https://externals.io/message/114324 > > - https://externals.io/message/111590 > > > > I followed those discussions closely back then, and I suppose the > > general sentiment (to which I also agree) was that this is more of a > > code style consideration rather than a technical one. Although it's a > > cosmetic change, the fact that it will cause BC issues on older PHP > > versions was a significant concern; now more so after we had > > Constructor Properties for 4 years. > > > > I think you can gather more pre-RFC opinions from this mailing thread, > > especially now that this is brought up after a while since Constructor > > Properties were introduced. > > > > 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)`). > > > > Ayesh. > --000000000000d91b66061d82ce7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for sharing previous discussions, I will definitely= =C2=A0take a look at those before writing up the RFC.=C2=A0


>= 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::__construc= t()`, and if a semi colon is expected or not
(`public function __constru= ct(public int $foo);` vs `public function
__construct(public int $foo)`)= .
Thank you, these are very valuable points to address in the RFC.=C2= =A0

I can definitely=C2=A0feel that there will be some mixed opinion= s about semicolon=C2=A0vs no semi colon.


Best regards
Oliver Nybroe (he/him)


On Thu, 18 Jul 2024 at 11:49, Lily Bergonza= t <li= lybergonzat+php@gmail.com> wrote:
I don't view this proposition as a breaking ch= ange. The way I
understand it, writing an empty body for a constructor would
still work, but we would also get the option to just omit the
body altogether.

I think it would be a very sensible update. I also think it should
require a semicolon, just so we have the same kind of syntax
as interfaces.

I would love to see such a change!

On Thu, Jul 18, 2024 at 11:46=E2=80=AFAM Ayesh Karunaratne <ayesh@php.wa= tch> wrote:
>
> >
> > Hello internals.
> >
> > I am looking into making the constructor body optional in classes= , essentially allowing you to write
> >
> > ```
> > class User {
> >=C2=A0 =C2=A0 =C2=A0public function __construct(
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0private string $name,
> >=C2=A0 =C2=A0 =C2=A0)
> > }
> > ```
> >
> > Currently to make this code valid, it would have to be written th= e following way
> >
> > ```
> > class User {
> >=C2=A0 =C2=A0 =C2=A0public function __construct(
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string $name,
> >=C2=A0 =C2=A0 =C2=A0) {}
> > }
> > ```
> >
> > With the introduction or constructor property promotion in 8.0, w= e often see classes where the constructor has an empty body, and my guess w= ould be that this will only increase with the introduction of property acce= ss hooks in 8.4 which is allowed to be defined in the constructor also.
> >
> > This change would only be a cosmetic change and simplify the user= land code by removing two redundant characters.
> >
> >
> >
> > This would be my first RFC and I am willing to try and implement = it myself.
> >
> >
> > Best regards
> > Oliver Nybroe (he/him)
>
> Hi Oliver,
>
> Some links to previous discussions when this was brought up in the
> mailing list before:
>
>=C2=A0 - https://externals.io/message/114324
>=C2=A0 - https://externals.io/message/111590
>
> I followed those discussions closely back then, and I suppose the
> general sentiment (to which I also agree) was that this is more of a > code style consideration rather than a technical one. Although it'= s a
> cosmetic change, the fact that it will cause BC issues on older PHP > versions was a significant concern; now more so after we had
> Constructor Properties for 4 years.
>
> I think you can gather more pre-RFC opinions from this mailing thread,=
> especially now that this is brought up after a while since Constructor=
> Properties were introduced.
>
> 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)`).
>
> Ayesh.
--000000000000d91b66061d82ce7e--