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

Reply via email to