When a handler uses route requirements, calling the handler multiple times results in the requirement parameter being added to the parameters list several times. See #31, where this behavior was reported as part of a separate issue.
The function produced by compile-requirements for ningle-route was
closing over a single parameter list shared by all invocations of the
route function. The inner functions were pushing requirement
parameters on this list, which left it with parameters from the
previous run on subsequent runs.
Resetting parameters to nil before running the inner match functions
would be sufficient, but instead this replaces the somewhat-tricky
lambda-generating code with a more straightforward loop. Match
function lookup is still memoized as before, but instead of iterating
over a list of closures, the generated function just iterates over the
requirement parameters and match functions directly. The only values
closed over are the requirements args and the list of match functions;
hopefully this is un-tricky enough to avoid any future confusion.
There is also a (very) minor performance enhancement to be had here by
accumulating the match parameters once and reversing the list, instead
of producing several intermediate copies of the list with append as in
the previous code.
When a handler uses route requirements, calling the handler multiple times results in the requirement parameter being added to the parameters list several times. See #31, where this behavior was reported as part of a separate issue.
The function produced by
compile-requirementsforningle-routewas closing over a single parameter list shared by all invocations of the route function. The inner functions were pushing requirement parameters on this list, which left it with parameters from the previous run on subsequent runs.Resetting
parameterstonilbefore running the inner match functions would be sufficient, but instead this replaces the somewhat-tricky lambda-generating code with a more straightforward loop. Match function lookup is still memoized as before, but instead of iterating over a list of closures, the generated function just iterates over the requirement parameters and match functions directly. The only values closed over are the requirements args and the list of match functions; hopefully this is un-tricky enough to avoid any future confusion.There is also a (very) minor performance enhancement to be had here by accumulating the match parameters once and reversing the list, instead of producing several intermediate copies of the list with
appendas in the previous code.