On Fri, Jun 21, 2024 at 1:22 PM Larry Garfield <[email protected]> wrote:
>
> 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. :-)
I get that, and thank you for any free time you both spend here to
help php move forward. I don't mean to imply that some things don't
belong here. However, it does seem like some pieces will need more
fleshing out than others. It would be nice if those that require less
fleshing could proceed without being delayed (or completely rejected)
by those that need more. But it sounds like this is meant to be an all
or nothing type thing.
> As noted above, I don't think it's feasible to postpone this one. It's also
> pretty simple, and wouldn't have any conflict with enums unless we went all in on the guards
> options, which we most likely will not in the initial version.
That's good to hear. This is one of my top requested items in this rfc
and would love to see it sooner than later.
> As noted, this is on the ADT hot path so postponing it is problematic. Especially holding it
> on type aliases, which have been discussed for longer than this RFC has been around (nearly 4 years)
> and yet no actual proposal has ever been put forward. It's unwise to wait for such a feature,
> especially when most likely implementations would dovetail well with patterns anyway.
I should clarify I'm not suggesting to postpone based on this
hypothetical feature. Maybe it wasn't a good one, but I'm just
throwing out some potential curve balls that could be brought up
during discussion. This is one of the items that seems to need a bit
more fleshing out than others, and might potentially lead to further
delay or an outright rejection and missing out on some good pieces of
this rfc.
> To clarify here, these all come as a set. Array shapes aren't their own
> "thing", they just fall out naturally from array patterns. So it's not possible for
> associative patterns to conflict with array shapes, as they are literally the same thing. :-)
> I'd have to check with Ilija but I don't believe there's much internal difference
> between list and associative patterns. This one isn't on the ADT hot path, so it could be
> postponed
>
> I see no way for associative array patterns/shapes to conflict with generics at all.
Thanks for the clarification. I was looking at the example given in
the overview trying to figure out the boundaries between array
structure patterns, array shape patterns, and nested patterns. It
sounds like it can be summarized to nested patterns with the option to
add or omit ... determining if unexpected key/values are allowed.
Also again, just throwing out hypothetical curve balls that could
delay or halt other good parts. At this point I don't actually expect
generics to ever be a thing.
> > 8. Capturing values out of a pattern and binding them to variables if matched
> > Ok I think that's stepping a bit far out of scope. Maybe is should
> > simply check and not have any side effects.
>
> As above, this is core functionality of pattern matching for ADTs, as well as a core feature of
> every other language that has pattern matching, I believe. It's not out of scope, it's
> core scope.
Ok, it just seems like a rift between expectations and reality. When
looking at things like this, if it is not actually something that's
new to me, I like to try to put myself in the shoes of someone who it
would be new to. Why? Because there are things that you can assume a
syntax does, and there are things you would only know a syntax does by
reading the docs (if it's not buried too deeply and you can find it).
I would never have assumed that there was a pattern to be appended to
$foo is Bar that would automatically assign one of its properties to
another variable if there was a match. But I guess that comes from
ignorance as I haven't had the luxury of familiarizing myself with a
language that does this. So if it is a common thing then I will chalk
it up to a bad assumption of mine.
> > 9. match .. is
> > Nice shorthand to have but i'd rather not see short hands forced in as
> > an all or nothing type thing as was done with property hooks. I'd also
> > argue that maybe short hands should not be added until a feature has
> > been around for at least one release and is generally accepted. That
> > way we're not using up syntaxes and limiting the ability to add other
> > syntax features without breaking backwards compatibility. Keep in mind
> > that the is functionality alone allows this (or at least it should)
> > and a shorter version may or may not be desired.
> > ```php
> > match(true) {
> > $var is Foo => 'foo',
> > ...
> > }
> > ```
>
> This is also core scope of pattern matching in most languages. It's not just a shorthand,
> it's a direct enhancement.
I didn't mean to downplay the usefulness of this. I do think it would
be incredibly useful, and would most definitely use it. To me a short
hand is always a direct enhancement. So when I say something is a
shorthand I'm not downplaying its significance at all. Although
convenient and will allow us to skip ahead in the timeline, I just
think shorthands should come after a feature, not at the same time.