Re: RFC: Improving the rack parameter normalization

andy
Sat, 08 Aug 2009 12:08:37 -0000

Hmm... I think you''re right, and especially with ordered hashes being
standard in ruby 1.9 it''s a very natural choice.

It will still leave a pretty ugly and ill-defined piece of code in
rack, and maybe that should be addressed, but it''s not needed for this
if we adopt your approach. By ill-defined I mean that trying to
describe what it actually does in any sensible fashion is extremely
difficult. Descriptions of what it''s intended to do are generally
quite succinct, but in fact, it''ll take a parameter assignment like
''a
[[[[[][][b][][c]][][[[[[[[[x]=1'' and yield
{"a"=>{"b"=>[{"c"=>
[{"x"=>1}]}]}}, and assigning "a]b[=3" yields
{"a"=>{"b"=>nil}} and
other such bizarre cases. And even seemingly well-formed cases can
yield unexpected results, like the situations I''ve already talked
about where a nonuniform set of subforms might, with rack''s current
behavior for embedded "[]", end up mixing attributes from different
subforms into each others'' records.

So I know rack is a separate offering from rails, but it seems the
rack parameter parser was largely adopted from rails, and the
connection is pretty tight. If a general clean-up of the rack
parameter parser is worth doing, would that likely be driven by this
community?

-andy

On Aug 7, 9:17 pm, Mateo Murphy <mateo.mur...@gmail.com>
wrote:
> Correct me if I''m wrong, but couldn''t this be solved by
having rack
> return ordered hashes?
>
> On 6-Aug-09, at 11:06 PM, andy wrote:
>
>
>
> > The problem is that rack loses this ordering information, and
I''m
> > pretty much convinced that it can''t be made to keep it.