hello,
- r() already supports full regex patterns (perhaps without special extras such as "/x" but that can be, I believe, patched.)
it does! i wrote any [qw| post get |] , r( qr( / ([^/]+) # the class / ([^/]+) # the object / ([^/]+) # the action /?$ )x ) , sub { "Yeah" } and it worked! and then i was confused because the r() became useless noise.
r('/.+/\w+_\w/'); is easier and more readable than: qr/\/.+\/\w+_\w\//;
It's true - however - that we could try and encourage a bit more readable regex patters: qr{/.+/\w+_\w/} Still, readability suffers.
qr(/.+/\w+_\w/); r('/.+/\w+_\w/'); Both are readable for me.
However, there are certain benefits to discuss and perhaps we'll add your patched. Since it's not something so trivial, a discussion will ensue. :)
Ok so i try to sell my point of view :) * r('') is code to maintain :-) * i really agreed your concern about readability but i don't understand why qr() is harder to read than r(''). I think qr() could be more readable in large applications: r('') does not use /x for the moment. as /x is a very good practice that is: - recommended in the "Perl Best Practice" - defaut behavior in perl6 - very addictive for those whom still use it so i think qr( / ( borrower | book | shelf ) # Bizness objects / ( delete | create ) # Crud actions / ( \d+ ) # id ) is way easier to maintain than r('/(borrower|book|shelf)/(delete|create)/(\d+)') About the feature proposed in my former message: qr( / (?<class> borrower | book | shelf ) # Bizness objects / (?<action> delete | create ) # Crud actions / (?<id> \d+ ) # id ) , sub { splat->{capture}->{action} } In the current Dancer behavior, you'll write '/:class/:action/:id' seems easier but: - you have to test all the captures in the code, which i think is a big readability issue: unless ( my ( $action = splat->{action} ) ~~ [qw/ delete create/] ) { not_found("$action isn't a valid action"); } - you'll match tons of urls too soon so it could be very hard to write smart dispatcher. for exemple, i think '/:class/:action/:id' can't be splitted in 2 rules like this get qr( / (?<class> program | library ) / (?<action> test | make ) / (?<id> \d+ ) )x, sub { "rule 1" }; get qr( / (?<class> documentation | tickets ) / (?<action> publish | alert ) / (?<id> \d+ ) )x, sub { "rule 2" } Finally, and even i prefer the qr() approach, i don't see why both syntaxes can't cohabitate in Dancer. regards, marc