Re: [whatwg] New URL Standard

On Tue, Sep 25, 2012 at 5:14 PM, David Sheets <kosmo.zb@gmail.com> wrote:

> Looking up keys is easy in an association list. Filtering the list
> retains ordering. Appending to the list is well-defined. Folding into
> a dictionary is trivial and key merging can be defined according to
> the author's URL convention.
>

I'd suggest writing out what you mean in JavaScript or JS-like pseudocode,
demonstrating what it would actually look like to scripts and how it would
be used.  It's the quickest way to get API ideas across.

 > The right approach is probably to expose the results in an object-like
> form,
> > as Tab suggests, but to store the state internally in a list-like format,
> > with modifications defined in terms of mutations to the list.
>
> This sounds more complicated to implement while maintaining
> invariants. A dictionary with an associated total order is an
> association list.
>

I think it's pretty straightforward both to specify and to implement.  Of
course, implementations can use any internal data structure they like as
long as the end result is the same.

 Why hide the order?
>

Because the natural JS interface, object-like access, doesn't allow it.  If
you think there's an API with similar convenience to an object and natural
usage in the language, then feel free to suggest it as I described above.

(Of course, a separate method could exist to get access to the underlying
order, if and when real use cases turn up that actually need it, and it's
not unlikely that there are use cases--but so far they haven't been
raised.  There's nothing wrong with exposing multiple API "views" into the
same data set, when they have clearly distinct goals and attempts to meet
both sets of goals with the same API fail.)

 >> Like: query = new URL("?a=b&c=d"); query.query["a"] = "x";
> >> query.toString() == "?a=x&c=d";
>
> > That won't work, since "?a=b&c=d" isn't a valid URL.
>
> "?a=b&c=d" is a valid URI reference. @href="?a=b&c=d" is valid.
>

It's not a valid *absolute* URL, which is what you used above.  You can
sidestep this either by prefixing it to make it into a valid URL (as I
suggested) or by specifying a base URL; they're both pretty much equivalent
here.

 This is a use case for parsing without composed relative resolution.
>

Maybe, but that's a pretty complicated approach for this use case.

(To summarize the mechanism he's referring to, as I understand it: the
ability to use this API to parse, modify and output relative URLs without
resolving them to a base URL at all.)

-- 
Glenn Maynard

Received on Tuesday, 25 September 2012 22:53:57 UTC