Skip to content
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

Use possessive quantifiers in routing requirements? #818

Closed
javiereguiluz opened this issue Jun 21, 2018 · 2 comments
Closed

Use possessive quantifiers in routing requirements? #818

javiereguiluz opened this issue Jun 21, 2018 · 2 comments

Comments

@javiereguiluz
Copy link
Member

javiereguiluz commented Jun 21, 2018

As @stof explained in #817:

I suggest using a possessive quantifier to improve the route matching performance (Symfony generates possessive quantifiers for its builtin requirements, but custom ones need to do that themselves, as using non-possessive quantifiers can still be a valid use case)

He's technically right, but we need to decide if we do that in this Demo app or not:

// BEFORE
@Route("/{id<\d+>}/edit",methods={"GET", "POST"}, name="admin_post_edit")
@Route("/page/{page<[1-9]\d*>}", defaults={"_format"="html"}, methods={"GET"}, name="blog_index_paginated")

// AFTER
@Route("/{id<\d++>}/edit",methods={"GET", "POST"}, name="admin_post_edit")
@Route("/page/{page<[1-9]\d*+>}", defaults={"_format"="html"}, methods={"GET"}, name="blog_index_paginated")

Some pros and cons:

  • (Con) This is a Demo app not a benchmark app, so clarity is preferred over speed.
  • (Con) The \d++ and \d*+ can confuse lots of developers who don't know regexp well
  • (Pro) Using these can be a good opportunity to help teach about them.
  • (Pro) It makes the routing slightly faster
  • ...
@stof
Copy link
Member

stof commented Jun 21, 2018

another pro: it demos the faster practice, so users may use it in their own projects too (which probably wants performance as it would not be a demo)

@javiereguiluz
Copy link
Member Author

Let's close this as "won't fix". I still think that the potential confusion of doing this change is much bigger than the small performance improvement. Thanks for understanding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants