On Fri, Jun 21, 2024 at 9:33 PM Larry Garfield <la...@garfieldtech.com> wrote: > > On Fri, Jun 21, 2024, at 3:35 PM, Brandon Jackson wrote: > >> Ilija and I have been working on and off on an RFC for pattern matching > >> since the early work on Enumerations. A number of people have noticed and > >> said they're looking forward to it. > > > > Hi Larry, I have definitely been looking forward to this. Perhaps more > > so than property hooks and avis. > > > >> By "very high level," I mean, please, do not sweat specific syntax details > >> right now. That's a distraction. What we're asking right now is "which > >> of these patterns should we spend time sweating specific syntax details on > >> in the coming weeks/months?" There will be ample time for detail > >> bikeshedding later, and we've identified a couple of areas where we know > >> for certain further syntax development will be needed because we both hate > >> the current syntax. :-) > > > > I think that a lot of this would be best broken up. Although much of > > it is aimed towards the same general idea, a lot of the pieces have > > specific use cases and special syntax additions. Overall I think this > > rfc should be simplified to just pattern matching with the `is` > > keyword with the patterns limited to what can be declared as property > > types (DNF types) and future scoping everything else. Maybe possibly > > with the addition of 1 or 2 of the top requested `is` pattern matching > > capabilities as secondary votes. > > To give more context, as noted, this is a stepping stone toward ADTs. > Anything that is on the "hot path" for ADT support I would consider > mandatory, so trying to split it up will just take more time and effort. > That includes the object pattern and match support, and the object pattern > realistically necessitates literals. Variable binding would also be almost > mandatory for ADTs. I'm very reluctant to push off anything in that hot > path, as every RFC has additional overhead, and I'm all volunteer time. :-) >
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. > > --Larry Garfield Robert Landers Software Engineer Utrecht NL
