Douglas Wilson

> I think we should change .all to simply add middleware and not affect options responses. Yes, it will be slightly different than app.all, but whatever. FYI `route.all` never did...

Adding `route.use` should be trivial for 4.x, right? I was thinking of adding it for the 4.5 release.

@nakedible after re-reading your original posts, it is clear you are confusing `app.all` behavior with `route.all` behavior: `app.all` adds 24 handlers and affects OPTIONS, but `route.all` does not and only...

Anyway, a `route.use()` that just operates like `route.all()` but strips the path does not seem useful, because of course the path will always be `/`. BUT I think `route.use()` would...

@defunctzombie you're thinking a signature of `route.use(path, fn)`, right (where `path` defaults to `'/'`)?

Well, I don't see how that would really build trees, then? Do you have an example? My only example I can think of is ``` js var userRouter = express.Router()...

Actually, the above would never work, because `.route(path)` matches up the full path, so `/user/1` would never come through there.

Well, I just realized that `route(path)` does a full match on the path, so like `path` to use would essentially only match downwards, like `app.route('/users/:id').use('/users', fn)` would work, but `app.route('/users').use('/users/:id',...

> Right, the .use would be path after stripping away the route's path. What I'm saying is that the route's path is actually a match-to-the-end match, so `app.route('/users')` would not...

> It seems that having this feature is useless then? Right. So the only use I could come up with was the one above, which would let a user do...