Re: [css-houdini-drafts] [worklets] First pass of fixing import for worklets.

> I don't really agree, because I think the idea of objects having 
realms is a bit unnatural.

I honestly don't see why.  Especially for IDL objects, which are 
explicitly specified as "having realms".

But more to the point, it's not whether objects "have realms" or not 
but whether they are associated with some particular state that may 
happen to be associated with a Realm, or may not be.  In this case, a 
base URL, or a source of such.

> I think if anything I'd expect the object's realm to be that 
detected via its __proto__ chain

That's obviously not workable in general because the proto chain may 
not lead to anywhere.... And yes, I know that some ES builtin objects 
work if you null out their proto and some start misbehaving badly, 
basically depending on whether people tried to make things work that 
way or not.  It's quite inconsistent and a bit annoying, really.

> In other words, putting on my naive developer hat, I'd conceptualize
 import to be written as something like

That's fair, except that's not how other things that do base URLs in 
the platform work.  Ignoring for the moment that `location.href` has 
nothing to do with the base URL of anything in general, they 
effectively (in the naive developer sense) capture the thing that has 
the base URL they care about in a closure when they are created and 
use it thereafter.

> I'd have no way to get "relevant" from JS code

You can think of "relevant" as a symbol-named property on the `this`, 
or something that symbol-named "non-public" functions that do the real
 work close over.

Or heck, a value stored in a weakmap.

> it seems that the function that I happened to call to trigger the 
load is the one doing URL resolution

Again, that's not how anything works in the web platform right now.  
In practice the model is that all the API functions call some sort of 
internal functions that do the actual work.  This is in some sense an 
accident of history (in that the internal functions are implemented in
 C++ and whatnot), and we can obviously have an argument about how 
important consistency is.  But that's how things work right now, and 
trying to change the model piecemeal is not very appealing to me, 
precisely because it means we throw consistency out the window 
forever.

> I can't tell if you're advocating for a more general "relevant by 
default, current when nothing else makes sense" position

I'm not sure whether I am.  I'd have to see what things do in 
practice, and in particular what uses people actually have for 
settings objects.  We have some obvious uses: base URLs (uses entry or
 relevant), initial prototypes for newly created objects (largely uses
 relevant in browsers, but uses current in some cases when the 
creation is done by the binding layer itself; think rejected promises 
when the `this` is the wrong type).  Fetch clients, I have no idea 
what browsers do.  Other uses?

It seems to me that such a survey is well worth doing before deciding 
what our general advice should be, because we should be valuing 
compatibility and consistency over theoretical purity...

> (We should probably also include a note that in constructors, 
relevant = current.)

As usual, "sort of".  The relevant settings of the object that gets 
created == current.  But the relevant settings of `new.target` of 
course might not match current.  Whether anyone cares about the 
relevant settings of `new.target` in a constructor ... I don't know.

Note that I'm on vacation for the next week, so responses will be a 
bit laggy, sorry.

-- 
GitHub Notification of comment by bzbarsky
Please view or discuss this issue at 
https://github.com/w3c/css-houdini-drafts/pull/251#issuecomment-229499123
 using your GitHub account

Received on Wednesday, 29 June 2016 21:47:00 UTC