5

I'm working on an implementation of a webform decoder and am looking to support the nested webform pattern employed by PHP and Ruby/Rails (possibly amongst others).

PHP: parse_str(); Ruby: Rack::Utils.parse_nested_query()

I've noticed some inconsistencies, for example (behaviour is the same in both languages):

foo=One&foo=Two
=> {'foo':'Two'}

foo[][bar]=One&foo[][bar]=Two
=> {"foo":[{"bar":"One"},{"bar":"Two"}]}

Here identical keys are discarded if at the top-level, but respected if at they exist lower down.

Is the rationale behind this design documented anywhere? Was the Ruby/Rails approach based on the PHP design (or vice-verca)?

20
  • 3
    @RobertHarvey the differences in syntax and philosophy are irrelevant for the purposes of this question: their handling of webforms (in terms of map, array and string primitives) they are remarkably similar. I'd like to know why.
    – rgchris
    Mar 19 '18 at 22:33
  • 6
    @RobertHarvey 'why did some language designer make some design decision' is not a meaningful question —isn't that the purpose of this site?
    – rgchris
    Mar 19 '18 at 22:37
  • 4
    One purpose of this site is to answer questions about software design. But we cannot tell you why one language or framework designer made one choice and another made a different choice. We would be guessing. Unless, of course, the language designers just popped in to answer the question. A question that only specific people can answer isn't a good fit.
    – Thomas Owens
    Mar 19 '18 at 23:12
  • 3
    If you have a problem, please take it to Meta. But we cannot answer this question here. Our speculation on what these language designers were thinking would be opinions.
    – Thomas Owens
    Mar 20 '18 at 0:20
  • 6
    I disagree with the hold. Almost any question of the form “what is the rationale for design pattern X” could conceivably get a biased, opinionated reply, but I would see that asthe fault of the reply-er. The phrasing, “Is the rationale behind this design documented anywhere?“ seems to alliw for fact-based answers, “yes, here it is...” or, “not that I could find”
    – joel.neely
    Mar 20 '18 at 19:50