On Friday, 21 June 2024 at 23:58, Robert Landers <landers.rob...@gmail.com> wrote: > As a user of PHP, this statement concerns me. I don't want any > features rushed just because someone wants it "now" and thus end up > with something feeling half-baked, missing important features or not > completely thought through. I think it's pretty fair that this is a > pretty big RFC (as in scope). Were it a PR under review, I might would > ask you to break it up into smaller PRs because it's too big to > discuss properly and were it smaller PR's we would probably arrive at > a better solution than the giant PR. > > Perhaps, it might be worth breaking up into sub-RFC's (is that a > thing?) where each pattern/feature can be discussed independently and > the vote is whether or not it gets implemented in the parent RFC but > has no binding on the parent RFC. Some things may be easy to discuss > (such as type matching) but others might be longer (such as as, or > arrays). But (and this is the key part) it wouldn't stop you from > proceeding on the parent RFC, which is implementing pattern matching > (in general) and any passed sub-RFC's. > > Maybe that could be a path forward? I don't know who makes the rules, > but they're human rules and they can be anything -- in theory. Maybe > "sub-RFC's" needs an RFC to define it, but that might let you move > faster than a) trying to do everything all-at-once, and b) let > hard-to-define parts of the overall feature get the time they deserve.
Breaking up an RFC into sub-RFCs which are each interdependent for the greater scope to be coherent doesn't make any sense. An RFC being "large" is not an issue. Moreover, this RFC is *already* a "sub-RFC" of the much larger in scope meta ADT RFC. The scope of this RFC seems pretty moderate to me and well appropriate, and part of this discussion is to establish what may be moved to later. It is always possible to break down an RFC into new tiny RFCs about every single possible design decision, it doesn't mean this should be done. Writing RFCs, discussing them, and responding to feedback is extremely exhausting and time-consuming, as such the authors of an RFC are entitled to decide what is in scope and what is not. They also decide what can be moved out, and what cannot. Part of being an RFC author is to *also* stand your ground on the scope and design of your RFC while taking into account the feedback. Best regards, Gina P. Banyard
