shit this should of gone out in the 0.5.0 release

This commit causes the following failure: https://intertwingly.net/projects/AWDwR3/checkdepot/section-21.html

Specifically:

     1) Error:
    test_alternate_routing(RoutingTest):
    ActionController::RoutingError: No route matches "/shop"
      2) Error:
    test_method_specific_routes(RoutingTest):
    ActionController::RoutingError: No route matches "/store/checkout"
      3) Error:
    test_recognizes(RoutingTest):
    ActionController::RoutingError: No route matches "/store"
      4) Error:
    test_routing(RoutingTest):
    ActionController::RoutingError: No route matches "/store"

I didn't bump the version, so you'll need to pull from the latest.

Updated: https://github.com/josh/rack-mount/commit/ca17250590d9288e81958fe46567504d58b85251

didn't seem to help, the env generator should give it `call' its own env

let me know what I need to do to make it more fair

duh! thanks, i thought something was up.

btw, this benchmark is really stupid, just static routes. mainly to separate out those using a linear search from a real data structure.

feel free to include me in your benchmarks. my generations are totally unoptimized so you could totally bash'em ;)

Fixed now. Only alters requests that are "partial matches", and thus, subject to stackability.

Hmm. I think this is because the Usher Rack interface is currently mutating the environment, thus, all the subsequent requests are to 404s. Lemme see about that one.

I must confess I am am quote nazi too, except the other way round: I always use double-quotes instead of mixing single with double.

I thought I was the only person who cared about this. :) I try to be biased towards single quotes because it communicates my intention that the String should not have any variable interpolation within it. I only use double-quotes when I’m interpolating via

#{}

.

josh: Will do, thanks.

If you wana fork and make that change, I’ll pull it in for you :)

(Sorry for the typo my first comment, it should have read after, not *after@.)

In my opinion, if #map_resource modifies the options hash, then it should be the one to make a copy before calling destructive methods, it’s not up to the caller to do so (unless the caller expects it, in which case #map_resource should be named something like #map_resource!).

The begin statement should be placed *after@ the namespace is pushed onto the stack, because the call to #pop in the ensure block should not be run if an exception is raised before, or during the call to #push.

@josh: oh heh, I’m not actually using rack-mount yet. I’m just an interested lurker atm. :) The project interests me alot because I think having a decent router at the rack level would be awesome. Most frameworks essentially duplicate the same core functionality for their routers, just using different DSLs — so it will be nice to offer a framework agnostic router to use instead. There’s also the obvious performance benefits moving the router to earlier in the request life cycle.

Whoa, your actually using rack-mount!

No, but thats really cool. I still have an enormous work todo still in terms of getting 100% compat with the Rails and Merb router. Plus I have a million more ideas to try to speed up the performance.

I don’t see that you have forked yet :)

@josh: Interesting to hear about Hash#[]= freezing the key, I didn’t know that.

It wasn’t something I feel too strongly about. I was just trying to point out something I noticed caused a few weird issues for me in other contexts. Now the pattern I usually use when I want to store a value inside my object, but not have any side effects on caller (or for later modifications of the caller object to effect my object internal state) is: arg.dup.freeze

Removed value freeze: ad9443a5b

Well there is precedent for this, since Hash[]= does call freeze on the key but not the value. I could remove the freeze from the value I guess. Anyway this all doesn’t really matter because its just internals.

However, the true motivation came from some bazzar ass jruby bug. For some reason the array of keys pass to another method were getting mutated some how. Freezing those args helped expose the bug, and I just kept the freeze there I guess.

Doesn’t calling freeze on the key/value passed in also freeze the object in the caller, given that they are references to the same object? I’m not sure if that’s your intention, but in general I think methods shouldn’t have a side-effect of changing state in any arguments, unless it’s part of it’s stated purpose.