-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: named capture groups #206
Comments
If we decide to extend Cucumber expressions, which ever syntax we pick, we should take some care to ensure that we don't collide with existing usage. For this example, people may already use I can also image that Behat users would like to continue to use their turnip expressions. How would be facilitate this? The one thing we can probably do without breaking things is make the |
This part's fine, they'd just import a different attribute (~= annotation in Java) I think we can restrict it to attributes rather than the older comment-style annotations I showed above: use Behat\Given as OldGiven;
use Cucumber\Given;
...
#[Given('I eat {string}')]
#[OldGiven('I eat :fruit')] |
Agreed, it doesn't look as if the grammar restricts it at all so it may be tricky to find a syntax |
Thinking about it, the grammar doesn't restrict what chars are allowed but I bet if we fuzz the existing parser implementations a little we can find some chars that aren't currently allowed :) My pref would be I'd quite like something along the lines of:
Even if we break backwards compatibility we could do that in an Expressions major (depending on the impact that has across different package manager ecosystems) |
I would prefer to keep all the syntax inside the
Now I really don't see a way to make this graceful, but if we release this with a feature toggle, we can also smooth out other migration problems i.e. I'd like to use this in Cucumber JVM but not enable this until the next major of Cucumber-JVM. Otherwise all future patches get stuck behind this breaking change. |
Nice :) FYI The way we do it in behat is we match on name first and then on position, but there are some awkward edge cases
(we also populate some arguments from a DI container) We don't currently implement type-based matching though and I'm wondering if that'd be a nice feature to add, given Cucumber Expressions can capture value object types explicitly |
@mpkorstanje a feature toggle is a GREAT idea to avoid the BC issue entirely |
If it's feature-toggled perhaps I'll pilot this in the PHP implementation? |
Ah fair enough. I'll stick to positional until someone asks for it. Anyway, what about |
I think that's |
Sure, but how would it or the equivalent turnip or regex with named groups map? How would a regex with named and unnamed groups match? |
I just want to give this a big 👍 Seems like it could open up some interesting possibilities. |
I would really like to have this feature too. Having named arguments prevents many mistakes when just ordering is used, especially early on when the expressions change often. As for having multiple definitions for the same name - I think that this should be an error. Regex from my experience also fails to compile when there are multiple capture groups with the same name. And I also think that we cucumber could disallow mixing named and positional arguments. One expression would have to commit to one or the other. I personally don't see a scenario where that would cause issues. Otherwise I am also in favor of the As an aside, what would have to happen now for this to move forward? Is there some formal RFC process or does this just need implementation? |
I've been looking at how cucumber-expressions could be adopted in Behat.
One feature of our existing two pattern syntaxes (regex and turnip) is that they can name the arguments.
e.g.
This allows Behat to match arguments based on name as well as position, letting users transpose the argument order if necessary.
That can be useful if multiple patterns are attached to one step, something allowed in Behat:
The new feature would be for Cucumber Expressions to capture argument names:
{fruit:string}
)Then it would be up to the Cucumber implementation to either use the names for matching to the step definition, or to ignore them and use the order directly as currently happens.
The text was updated successfully, but these errors were encountered: