Re: URLQuery / FormData

On Tue, Sep 10, 2013 at 10:44 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: Anne van Kesteren [annevk@annevk.nl]
>
> > I'd be interested in hearing what they have to say though.
>
> Well, since you asked... :)
>
> My primary concern is not deriving something from `Map.prototype` on which
> the `Map.prototype` methods don't work as normal (e.g., can't store
> objects, or setting-then-getting doesn't return the same value, or
> similar). But I think that's not even being considered, so I'm mostly
> happy. In that light, what follows is just idle musing.
>
> My other perspective comes from working with headers and form-encoded data
> in Node, where their multi-valued nature is, depending on the framework,
> often completely broken by trying to hide it. This has made me value making
> it evident and obvious that multiple values can be stored for each key, as
> a prominent part of the API. That's why `append` was so appealing to me,
> leaving `set` out: it is no less convenient to use than a single-valued
> map's `set` would be, but it's much more clear in terms of surfacing the
> underlying concept.
>
> If I found it really important to make these things conform to some sort
> of map structural type, I would take one of two routes:
>
> 1. Study multimap contracts in other languages, which I believe Tab is
> citing, and try to emulate them. (But, of course, it's not a true `Map`
> since it's type-restricted, so you have to adjust some stuff there.)
> Importantly, do other languages, preferably ones with structural types,
> reuse the same method names for different semantics?
>
>   This may be a more awkward API, but perhaps re-using an awkard
> string-only multimap API across parts of the platform is better than coming
> up with a pleasant-but-conceptually-less-general API for these two use
> cases, or others like them. I am not sure I see the benefit, and if I were
> writing this library in JavaScript-as-it-is I would not try to create
> something general but instead serve the use case. But, it's a conceptually
> sound option.
>
> 2. Treat this as essentially a map of strings to arrays of strings, and
> add sugar methods for handling this. So, for example, `get` would return an
> array, `delete` would delete the whole array, `set` would reset the whole
> array (taking an array as a parameter), and `append` would add an element
> to the appropriate array at the given key (creating the entry if it doesn't
> exist). This is essentially your API, but with an array-taking `set` added.
> (Notably, we could add `set` at a later date if people really want to treat
> these things as maps of strings to arrays.)
>


In support of #2, one of the most important aspects of jQuery's success
with developers was the elimination of "modes" with regard to: 1) a single
element, 2) a node list. This was my basis for suggesting to Anne that
"modes" be eliminated from the design. Instead of trying to make an API
that has a function for returning one value (or the first of a set of
values) and another function for returning the entire set of values—just
have a single function that always returns the array value for that key,
regardless of the number of items stored. This approach also means that the
end developer doesn't have to remember when to use get() or getAll(),
because the "no-modes" version of get() always returns the same _type_,
which also means that further operations on the value are as simple as
using the existing array methods (vs. needing to know if there will be a
single string value returned or an array of strings).


Rick