On Thu, Jul 18, 2024 at 4:40 PM Larry Garfield <la...@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-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
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.
