Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124483
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> <CAPPUTHo5g6gd=ZpYjEzXsRt1OYDs1zvxunWR115N1mOnh23ULw@mail.gmail.com>
 <667151f4-22c5-464d-a01e-ad2a36cb767d@app.fastmail.com>
In-Reply-To: <667151f4-22c5-464d-a01e-ad2a36cb767d@app.fastmail.com>
Reply-To: lilybergonzat+php@gmail.com
Date: Thu, 18 Jul 2024 17:04:16 +0200
Message-ID: <CAPPUTHrOrBUNZCdRtHSNN5J_uYv+who_QtJdimLyqfu4qnvHFw@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)

On Thu, Jul 18, 2024 at 4:40=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com> wrote:
>
> 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-s=
ized changes are easier to discuss.  However, they also attract more bikesh=
edding, and often a feature is not actually useful except in conjunction wi=
th other parts of it.  On the flipside, a tiny RFC has a hard time justifyi=
ng its existence, since whatever intended follow-ups that would make it act=
ually useful are never guaranteed to happen (either the authors lose intere=
st or they get voted down later, etc.).  Going through an RFC also has a lo=
t of process overhead, and breaking one small RFC into many tiny RFCs can a=
ctually take far longer than the one larger RFC.
>
> Conversely, an RFC can be too big to really comprehend, and then no one r=
eally understands what it's doing without hours of reading and research, an=
d 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 wit=
h the topic.  Also, the impact of an RFC often has very little to do with i=
ts 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 "r=
ight-sized" when it offers notable, meaningful benefit on its own, without =
"holes" in the functionality, but can and should have natural "extension po=
ints" 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 m=
eans something the size of property hooks. :-)  It's really a case-by-case =
situation.
>
> --Larry Garfield

I noted the "don't top-post" earlier, and I was very confused about
what it meant. I thought about it for a while and couldn't figure it
out so I just figured it was not to me. I understand, now, and I think
I am not top-posting right now? Thank you for giving me a nudge.

Also thank you for the in-depth explanation about the RFC size. I
understand your position now, and I think I mostly agree, fwiw.