Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128074 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 lists.php.net (Postfix) with ESMTPS id 7BCB31A00BC for ; Wed, 16 Jul 2025 06:46:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1752648288; bh=AcraTvdApxf3HFHZ9O018022GJNHxttqgofXvnrIij0=; h=Date:From:To:In-Reply-To:References:Subject:From; b=M/q+mKENH/Mav+8arcacuVZ/c8VCoKmy6o5bgP3G2rggztI7GJEZlV+ZrM+uZXsXC E3nvp9R2KZKHWRAiVCnbL66Ua7Fswu+sMfUMz27BUdM0v5pris9XxuqAeUBGhOqeXd POESe4y7tbTEDuffXpuKDP06MeNjnLVq5jRC6bCctNQebxjAVfTWbG/OULEOUz52iE 9NiVwFblCTb8MiTr+wIdbD5nevjm/RKe+yPfXmQa7uyl93IhrpRWe+rCO7DUrIwKKB 6ld0u8GcNnkeArF5HMsUz3uJKNxHAuvdl88QEJIiKgAMGfvOUe8w9IvholvixGokhX Pw5e+HuCBH24A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 86196180003 for ; Wed, 16 Jul 2025 06:44:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fout-b7-smtp.messagingengine.com (fout-b7-smtp.messagingengine.com [202.12.124.150]) (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 ; Wed, 16 Jul 2025 06:44:47 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 143831D00030 for ; Wed, 16 Jul 2025 02:46:34 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-05.internal (MEProxy); Wed, 16 Jul 2025 02:46:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1752648393; x=1752734793; bh=tdM6oBIFYo So4Vcv0VQ6M3L0Ubhn17Bs9CoCOj24et8=; b=Kl8X0KaMA9xd33qPFoTCtRn8rp B3aD5pEKlqmeA/5cGRhQlqv1A7BcScZVfoPd+rl5Y6V41bxs1eqCHsCLd0PbWvSG GVDgJa1uHEwOnGZyB/74RG1h5560/FOJgKOOXsp5nkfYkaA/Dof6dzWS73LZ+bbZ l7WgcEgkCK5lO2LKY8PwZ74N70XEbHbq44AmLs8PQgPFocSmRaBWBjkquHSgjxhc 7zdODJCk9Zl2DjLgBIxbPXu21tbFESqKl/q4lpQjku1rGZv9FEwn2SGc6W1wUNP3 BNuGb4FBnPn5SXQ31BjV77SF7ykMt7XTyYTbqHZWre3viZOioPaOXU/11bRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1752648393; x=1752734793; bh=tdM6oBIFYoSo4Vcv0VQ6M3L0Ubhn17Bs9Co COj24et8=; b=f4XPP+Rp0Xfo06V2t3YzmxNeSiDqxT0LLsAcqeDWisz4XJNHg67 suXV+Rb8rl7hC2x8dy/DVF1dOp8+TGoOz7OTGd9xaZKsO5hvmu7dc91KzDYf0Dbv SS4uNWjHejY7DRrFn+xqbQg9x+GF7+VUMaD6JYMsE/Ql94UzeHRajZK+t4n0Qf2D IwhiZfvW+gy2hvQNnSd+xG03+cy8mGR3tuo0s2E9iN5/LbknqAb0dY3mfGUqcaM/ j4YTlF83H0mCSmIyrzxs89QTe1zYiTnJqN2dMAXaV4WkdoUAkRehUJWcOjWSdMIA tjjBuShHc9y60B45XctIxGkskSh+fsvZDoA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdehjedtfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepofggfffhvffkjghfufgtsegrtderreertd ejnecuhfhrohhmpedftfhosgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdr tghouggvsheqnecuggftrfgrthhtvghrnheptddugfdvlefgheeigeffheeffedugfdtfe fgveduuedtgfdukeehffeljeehleffnecuffhomhgrihhnpegvgihtvghrnhgrlhhsrdhi ohdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdpnhgspghrtghpthht ohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepihhnthgvrhhnrghlsheslh hishhtshdrphhhphdrnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 726561820074; Wed, 16 Jul 2025 02:46:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: Tb5b4f3e5fa36e0f0 Date: Wed, 16 Jul 2025 08:46:03 +0200 To: internals@lists.php.net Message-ID: In-Reply-To: References: Subject: Re: [PHP-DEV] Discussion Short Constructor Content-Type: multipart/alternative; boundary=f709ad21349c4bed9660687d8999c997 From: rob@bottled.codes ("Rob Landers") --f709ad21349c4bed9660687d8999c997 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2025, at 20:07, Dmitry Derepko wrote: > Hi, >=20 > I've found a discussion about Records https://externals.io/message/125= 975 and found a one key point which I really like in Kotlin (hello): sho= rt constructors. >=20 > Rob said that short constructor will be probably removed: >> 1. Inline constructor isn=E2=80=99t necessary and could be proposed = separately. I=E2=80=99ve thought recently about this feature > I will probably remove this, to be honest. It was for nesting records = inside classes or other records, but this feature was declined, so there= isn't really a need for it. >=20 >=20 > Whether it's true or not I've played with syntax analyser and created = a sugared polyfill for short constructors: https://github.com/php/php-sr= c/pull/19133 >=20 > Many examples of how it works inside the PR, just read them. >=20 > Should I propose the RFC or not? >=20 > This step move us further to "light" structures or "heavy" structures = written "simple": >=20 > class RedBox extends Box(width: 50, height: 200); >=20 > $box =3D new RedBox(); >=20 > instead of >=20 > class RedBox extends Box { > public function __construct() > { > parent::__construct(width: 50, height: 200); > } > } >=20 > OR >=20 > class RedBox extends Box { > public function getWidth(): int > { > return 50; > } >=20 > public function getHeight(): int > { > return 200; > } > } >=20 > OR even with Single Expression Functions RFC: >=20 >=20 > class RedBox extends Box { > public function getWidth(): int =3D> 50; >=20 > public function getHeight(): int =3D> 200; > } >=20 >=20 > -- > Best regards, > Dmitrii Derepko. > @xepozz Hi Dmitrii, I meant that I'd remove it from the records RFC, not that I wouldn't eve= r pick it up. In fact, I put it on my todo list and announced it to this= list, 7 months ago: https://externals.io/message/125975#126029 Fun fact: it was a part of my original proposal with nested classes that= then got removed due to feedback. Why I haven't proposed it as a separate RFC: with PSR-4 being so popular= , nobody is going to write one-line files to take advantage of this. Thu= s, when I was going to revisit nested classes later this year (after all= the release shenanigans and some personal issues), I was planning to ad= d this feature to the nested class v2 RFC (again). A lot of feedback I g= ot on nested classes was "when would I use this?" -- and I suspect that = would be a lot of the feedback you'd get here (see: PSR-4). I'm more con= vinced than ever that short constructors and nested classes create a chi= cken-and-egg problem. They only really make sense together; at least wit= h our current coding conventions and standards. It will create a longer = discussion period, but that's fine, IMHO. If you'd like to continue with this RFC, I'd love to discuss it further = with you and help you out. I believe it is a bit more than "just" syntax= sugar, but I'd have to dig out my records implementation. =E2=80=94 Rob --f709ad21349c4bed9660687d8999c997 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul = 15, 2025, at 20:07, Dmitry Derepko wrote:
Hi,

I've found a discussion about Records https://externals.io/message/125975 and found a = one key point which I really like in Kotlin (hello): short constructors.=

Rob said that short constructor will be probab= ly removed:
  1. Inline constructor isn=E2=80=99t necessary and could be = proposed separately. I=E2=80=99ve thought recently about this feature

https://github.com/php/php-src/pull/19133

Many examples of how it works inside the PR, just read them= .

Should I propose the RFC or not?
This step move us further to "light" structures or "heavy" = structures written "simple":

class RedBox exten= ds Box(width: 50, height: 200);

$box =3D new Re= dBox();

instead of

class RedBox extends Box {
    public function __c= onstruct()
    {
      &nbs= p; parent::__construct(width: 50, height: 200);
    = }
}

OR

=
class RedBox extends Box {
    public fun= ction getWidth(): int
    {
    =     return 50;
    }

    public function getHeight(): int
=     {
        return 200;
<= div>    }
}

OR even with Si= ngle Expression Functions RFC:


class RedBox extends Box {
    public= function getWidth(): int =3D> 50;

&nbs= p;   public function getHeight(): int =3D> 200;
= }


--
= Best regards,
Dmitrii Derepko.
=

Hi Dmitrii,

I meant that I'd remove it from the records RFC, n= ot that I wouldn't ever pick it up. In fact, I put it on my todo list an= d announced it to this list, 7 months ago: https://externals.io/message/125975#12602= 9

Fun fact: it was a part of my original pr= oposal with nested classes that then got removed due to feedback.
<= div>
Why I haven't proposed it as a separate RFC: with PSR= -4 being so popular, nobody is going to write one-line files to take adv= antage of this. Thus, when I was going to revisit nested classes later t= his year (after all the release shenanigans and some personal issues), I= was planning to add this feature to the nested class v2 RFC (again). A = lot of feedback I got on nested classes was "when would I use this?" -- = and I suspect that would be a lot of the feedback you'd get here (see: P= SR-4). I'm more convinced than ever that short constructors and nested c= lasses create a chicken-and-egg problem. They only really make sense tog= ether; at least with our current coding conventions and standards. It wi= ll create a longer discussion period, but that's fine, IMHO.
<= br>
If you'd like to continue with this RFC, I'd love to discu= ss it further with you and help you out. I believe it is a bit more than= "just" syntax sugar, but I'd have to dig out my records implementation.=

=E2=80=94 Rob
= --f709ad21349c4bed9660687d8999c997--