-
Notifications
You must be signed in to change notification settings - Fork 196
Prototype for allowing immutable RouterInterface #189
Conversation
@@ -383,6 +392,10 @@ public function routeMiddleware(ServerRequestInterface $request, ResponseInterfa | |||
*/ | |||
public function route($path, $middleware = null, array $methods = null, $name = null) | |||
{ | |||
if (null !== $this->router) { | |||
// @todo should we throw an DomainException here, as routes cannot be added after the router was created? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See here.
@DASPRiD LGTM, but I think it could be named |
I'm still wondering what benefit this provides. Since we still end up with one mutable object (the "builder"), what does this extra indirection provide tangibly to the system or the end user? |
@weierophinney Once the router is created from the builder, it is save to assume that it is immutable then. The app doesn't call the builder twice. |
@DASPRiD My point is: the liklihood of adding routes after bootstrapping is ridiculously low, and we can instead specify in the current |
@weierophinney Well, if we kinda allow the router to freeze, that'd probably be fine as well I suppose. |
@DASPRiD We already have verbiage stating that Do you want to do a PR for that? Or alter this one? or leave it to me? |
Per zendframework#189, `addRoute()` **MUST** raise a `RuntimeException` if called after either `match()` or `generateUri()` have been called, to ensure the router state does not change between invocations.
Closing in favor of #202. |
This PR is aimed to make the
RouterInterface
completely immutable. The way to achieve this is by injecting aRouterFactoryInterface
into the Application, instead of aRouterInterface
. The factory allows the sameaddRoute()
method as the prior mutable router did. When requested, a router is build using the supplied routes.