Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124482
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <667151f4-22c5-464d-a01e-ad2a36cb767d@app.fastmail.com>
In-Reply-To: 
 <CAPPUTHo5g6gd=ZpYjEzXsRt1OYDs1zvxunWR115N1mOnh23ULw@mail.gmail.com>
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>
 <CAPPUTHo5g6gd=ZpYjEzXsRt1OYDs1zvxunWR115N1mOnh23ULw@mail.gmail.com>
Date: Thu, 18 Jul 2024 14:37:32 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] Optional constructor body
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jul 18, 2024, at 2:03 PM, Lily Bergonzat wrote:
> 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.

As you're new, I'll just note, please don't top post. :-)

The optimal size of an RFC is a very squishy topic.  There are some that argue for "the smallest possible and no smaller," on the theory that bite-sized changes are easier to discuss.  However, they also attract more bikeshedding, and often a feature is not actually useful except in conjunction with other parts of it.  On the flipside, a tiny RFC has a hard time justifying its existence, since whatever intended follow-ups that would make it actually useful are never guaranteed to happen (either the authors lose interest or they get voted down later, etc.).  Going through an RFC also has a lot of process overhead, and breaking one small RFC into many tiny RFCs can actually take far longer than the one larger RFC.

Conversely, an RFC can be too big to really comprehend, and then no one really understands what it's doing without hours of reading and research, and there's so many moving parts even the authors cannot keep track of them.  On the flipside, some parts just don't make any sense on their own unless combined with other aspects of a proposal.

So there's really no "natural" size for RFCs generally.  It will vary with the topic.  Also, the impact of an RFC often has very little to do with its length or number of features.  The RFC text for "don't require ; to end a statement anymore" would likely be pretty short, but would also break, er, everything. :-)

Conversely, offering a new syntax for abbreviated constructors (as being discussed here) would be longer than that, but the impact on existing code would be zero (unless it's done badly).

Also, "minor work" can end up causing problems for future work.  See also: readonly, which was intended as a "junior stepping stone" to more complex features, but as we've found, actually makes those future features *more* complex because it wasn't designed with those future expansions in mind.

My own stance (which I do not claim to be universal) is that an RFC is "right-sized" when it offers notable, meaningful benefit on its own, without "holes" in the functionality, but can and should have natural "extension points" where it will dovetail nicely with other, future features, which can be planned or not.  Sometimes that means a very short RFC, other times it means something the size of property hooks. :-)  It's really a case-by-case situation.

--Larry Garfield