Hey Pat,<br><br>It is quite easy to tighten up your regex's if it is truly a really simple case. As it gets more complicated it gets harder and harder and requires more and more time. The purpose of the change is not to make smarter matches, it is to remove this work from the process of writing steps and stories.<br>
<br>What happens if you want to match something with a space in it for instance? Also, putting the $ anchor directly after (.*) is redundant. In the cases where this helps the most, I would have either had to write negative lookahead regex's, or negative lookbehinds ( unsupported in 1.8).<br>
<br>- Jake<br><br><div class="gmail_quote">On Fri, Jan 30, 2009 at 2:29 PM, Pat Maddox <span dir="ltr"><<a href="mailto:pergesu@gmail.com">pergesu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Jan 30, 2009 at 10:18 AM, Jake Howerton <<a href="mailto:jake.howerton@gmail.com">jake.howerton@gmail.com</a>> wrote:<br>
> Hey All,<br>
><br>
> I discussed this option with Aslak in #cucumber and think I convinced him of<br>
> its value ;) Please chime in with any thoughts.<br>
><br>
> This feature is currently available in my github fork here:<br>
> <a href="http://github.com/jakehow/cucumber/tree/master" target="_blank">http://github.com/jakehow/cucumber/tree/master</a><br>
> Please pull and test if this matters to you or you are curious.<br>
><br>
> Way back in Story Runner ;), the order you defined your steps in mattered.<br>
> This allowed you to put steps in a specific order if you had more specific<br>
> steps that you wanted to match first. ( Aslak tells me this was a bad idea,<br>
> b/c different OS's order Dir[] differently). Either way I found it useful,<br>
> because it allows you to make a more specific step definition instead of<br>
> contorting your English in order to avoid multiple matches. Every time I sit<br>
> down with cucumber, I hit this issue, in cucumber you can at least make more<br>
> specific regex's, but this is also a pain, especially in complex situations.<br>
><br>
> Say we have two step definitions.<br>
><br>
> Then /the form has a field called: (.*)/<br>
> and<br>
> Then /the form has a field called: (.*) with value: (.*)/<br>
><br>
> By default this will raise a Cucumber::Multiple error because of the<br>
> ambiguousness of it from the regex standpoint.<br>
<br>
</div>Maybe. I think before introducing a funky ranking algorithm to match<br>
steps, it's probably best to make your step definitions more precise.<br>
This means using anchors and character classes.<br>
<br>
Then /^the form has a field called: (\S+)$/<br>
Then /^the form has a field called: (\S+) with value: (.*)$/<br>
<br>
Cucumber prints out (.*) in pending regex's because that's a pretty<br>
sensible default, and it doesn't have enough context to do otherwise<br>
really. A lot of times you can get away with being lazy and just<br>
leaving that (I know I do plenty) but when you can't, spend a couple<br>
minutes to tidy up your regexes.<br>
<br>
I do think your idea is cool :) but at this point it sounds like<br>
clean regexes are simpler and more effective, no?<br>
<font color="#888888"><br>
Pat<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
rspec-devel mailing list<br>
<a href="mailto:rspec-devel@rubyforge.org">rspec-devel@rubyforge.org</a><br>
<a href="http://rubyforge.org/mailman/listinfo/rspec-devel" target="_blank">http://rubyforge.org/mailman/listinfo/rspec-devel</a><br>
</div></div></blockquote></div><br>