Comments (13)
I would prefer to keep all the syntax inside the {}
. That way we would only limit the names of the parameters and not impact other parts of expressions. So:
{} // Anonymous, as is
{type} // As is
{:label} // Anonymous (.*) with a label
{type:label} // type and label
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.
from cucumber-expressions.
@mpkorstanje a feature toggle is a GREAT idea to avoid the BC issue entirely
from cucumber-expressions.
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 :
in their cucumber expressions.
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 TreeRegex
capture group name aware.
from cucumber-expressions.
I can also image that Behat users would like to continue to use their turnip expressions. How would be facilitate this?
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')]
from cucumber-expressions.
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
Agreed, it doesn't look as if the grammar restricts it at all so it may be tricky to find a syntax
from cucumber-expressions.
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 :
because it's like turnip, and because PHP is a dynamic language we often don't need to cast stuff.
I'd quite like something along the lines of:
{type}:{label} // does this collide with real-life usage?
{type} // to support current usage, omitting the colon is allowed if there is no label
:{label} // label-only so it stays as a string
{}:{label} // if the above is too BC-breaking we could allow empty type == string
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)
from cucumber-expressions.
I'd like to use this in Cucumber JVM
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
Given :X :Y :Z
function ($X, $Y, $Z) // as expected, matched on name
function ($a, $b, $c) // as expected, matched on position
function ($a, $X, $b) // would receive $a=Y $X=:X $b=:Z which can be counterintuitive with typos
(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
from cucumber-expressions.
If it's feature-toggled perhaps I'll pilot this in the PHP implementation?
from cucumber-expressions.
Given :X :Y :Z
function ($a, $X, $b) // would receive $a=Y $X=:X $b=:Z which can be counterintuitive with typos
Ah fair enough. I'll stick to positional until someone asks for it.
Anyway, what about Given {:A} {:A} {:A}
? Is that an error in creating the cucumber expression?
from cucumber-expressions.
I think that's {:label} // Anonymous (.*) with a label
from cucumber-expressions.
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?
from cucumber-expressions.
I just want to give this a big 👍
Seems like it could open up some interesting possibilities.
from cucumber-expressions.
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 {type:label}
grammar. Or {label:type}
since that is closer to what I'm used to, but either is fine.
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?
from cucumber-expressions.
Related Issues (20)
- Remove Python example illustrating how to define parameter types HOT 2
- more powerful optional text HOT 12
- Allow free-form text in optionals HOT 1
- Expression for an argument list HOT 4
- Improve Expression creation performance HOT 2
- Use action-publish-pypi in cucumber-expressions
- Optimize Cucumber expression creation in .Net implementation
- Action Required: Fix Renovate Configuration
- Bad CucumberExpression creation performance HOT 6
- Golang big.Float is not a big decimal HOT 12
- Missing source for source map
- RegEx "expressions" and defineParameterType feature file examples ?
- Add the ability to ignore a cucumber expression parameter just like a non capturing regex HOT 12
- Nested capture groups are not passed to custom param definition transformer HOT 8
- `end` as a method name / prop can cause some issues HOT 4
- LICENSE file is empty HOT 1
- Typo in error message for use of alternation inside an optional
- Unable to parse negative number in Norwegian HOT 11
- Released Ruby gem is missing LICENSE file. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cucumber-expressions.