Concerned we're going to see a lot of:

var requestURL = new URL(event.request.url);

e.g.: https://github.com/jakearchibald/trained-to-thrill/blob/3c6490361e1e373841de3ce8df82a195469be82f/www/static/js/sw.js#L20

Maybe. I don't want to return a mutable URL. Maybe something like http://url.spec.whatwg.org/#urlutilsreadonly Or we could offer a asURL() method that returns a new URL object each time.

  var requestURL = event.request.asURL()

(In reply to Anne from comment #2)
> Maybe. I don't want to return a mutable URL. Maybe something like
> http://url.spec.whatwg.org/#urlutilsreadonly

I like the readonly suggestion very much.

> Or we could offer a asURL()
> method that returns a new URL object each time.
> 
>   var requestURL = event.request.asURL()

This not so much; It's weird to have a url attribute which needs conversion.

On the other hand, URLUtilsReadOnly could have a clone (or toMutable) method that would return a mutable URL instance with the attributes set to the same value as the original one.

The asURL() suggestion was with the assumption we would keep url as returning a string.

The problem with #urlutilsreadonly is that it's a ton of attributes, including href.

(In reply to Anne from comment #4)
> The asURL() suggestion was with the assumption we would keep url as
> returning a string.

Yes. Still. It's weird.

> The problem with #urlutilsreadonly is that it's a ton of attributes,
> including href.

What's wrong with that? (Genuine question.)

origin is a direct conflict. href duplicates url.

You mean request.headers.get("origin") vs. request.url.origin?

(In reply to Tobie Langel from comment #7)
> You mean request.headers.get("origin") vs. request.url.origin?

I meant request.origin vs request.origin (if we implemented URLUtilsReadOnly on Request).

Changing request.url into returning an object of sorts would not match any existing pattern we have for URLs.

(In reply to Anne from comment #8) 
> Changing request.url into returning an object of sorts would not match any
> existing pattern we have for URLs.

I'm not sure I understand what that means.

What we have today is HTMLAnchorElement, HTMLAreaElement, and Location that all implement some variant of URLUtils. We don't have an object that has a property that returns an object that implements some variant of URLUtils.

Well, that's one way of looking at it. I see the location object as a property of the window object, so request.url being an immutable instance of URL really doesn't surprise me. (I find it consistant, actually.)

Fair. I guess then there's the question as to whether this should be a class or a record as per https://github.com/w3c/screen-orientation/issues/13#issuecomment-47595155

I suspect class since this might become mutable.

I'd like to push back a bit against the OP. I really liked the

var requestURL = new URL(event.request.url);

pattern when I saw it. It is a good way of having the platform expose (and accept) URLs in a uniform way, as ScalarValueStrings. That makes them easy to work with in various contexts where strings are simpler to work with. And it emphasizes to authors that you can manually construct a URL from any string at any time, when you want to get something mutable and decomposed. But that URL will be separate from the original one; it will be created specifically by you, for you.

Indeed, even if we create an immutable URL, people are still going to have to do

var requestURL = new MutableURL(event.request.url);

in order to get a mutable copy, for the cases where that's what they want.

This is already how things are done in Node, as one data point, although they call it `url.parse` instead of `new URL`.

---

All that said, if there is strong consensus that you need to design immutable versions of URL, URLSearchParams, etc., then I agree they would be classes, not records. Not because they are likely to become mutable in the future (wouldn't that defeat the entire point?) but because they are likely to have lots of shared behavior (like URLSearchParams's methods which access an internal multimap) in addition to simply storing data.

> Indeed, even if we create an immutable URL, people are still going to have to do
> 
> var requestURL = new MutableURL(event.request.url);

You could also add a clone method:

var requestURL = event.request.url.clone();

But that's a red herring if your plan is to drive people to use strings for URLs as much as possible. In which case, I agree, event.request.url should be a string. I also think new URL(str); instead of URL.parse(str); sends the wrong signal.

(In reply to Tobie Langel from comment #14)
> I also think new URL(str); instead of URL.parse(str); sends the
> wrong signal.

If this is the only thing standing from this bug -> WONTFIX. I've asked numerous times for feedback on the URL Standard. Nobody ever came with the argument that new URL(input, base) sends the wrong signal.

(In reply to Anne from comment #15)
> If this is the only thing standing from this bug -> WONTFIX. I've asked
> numerous times for feedback on the URL Standard. Nobody ever came with the
> argument that new URL(input, base) sends the wrong signal.

Agreed. I had incorrectly assumed the goal of having new URL() was to push devs to use URL objects instead of strings as much as possible. Turns out it's exactly the opposite. In which case, we should close this as WONTFIX and I'll open a bug against the URL standard for favoring URL.parse instead of new URL().

I don't see why we'd ever add URL.parse given new URL is a thing.

(In reply to Anne from comment #17)
> I don't see why we'd ever add URL.parse given new URL is a thing.

Well, I think we have to decide whether we want devs to use URL objects to represent URLs or use Strings instead.

If we want URLs to be mostly expressed as Strings, then we want a URL api that consists mostly of static functions (e.g. similar to what exists for JSON).

Otherwise, if we want mostly objects, then request.url should return one too.

Overall, I'm concerned that we're creating a similar situation as we have between the String constructor and string primitives. But maybe, this just shows a misunderstanding on my part.

(In reply to Tobie Langel from comment #18)

> If we want URLs to be mostly expressed as Strings, then we want a URL api
> that consists mostly of static functions (e.g. similar to what exists for
> JSON).
> 
> ...
> 
> Overall, I'm concerned that we're creating a similar situation as we have
> between the String constructor and string primitives. But maybe, this just
> shows a misunderstanding on my part.

I don't really see this as accurate. Having a structured class representing a mutable URL, versus representing a URL as a string, is a very different situation from having a useless immutable wrapper object (String objects), or stringifying/parsing arbitrary object/array/primitive graphs.

URL instances must come from somewhere. In theory they could have a constructor that is e.g. `new URL({ protocol, username, password, host, ... })`, or just `new URL()` (and then you individually set its components). And then `URL.parse` could generate an instance from a string. But in terms of ergonomic API design, I don't see that as a win. It doesn't seem to communicate anything different about how they are supposed to be used, certainly.