On 8/8/13 2:11 AM, Ian Hickson wrote:
I would imagine most languages other than JavaScript would break that
invariant.
Why are we suddenly worrying about languages other than JavaScript?
What other problems would it break?
Let me think about this; it's been a while...
Because the current spec effectively calls for the global to be a
proxy-like object (or some sort of object that's not describable in ES
spec terms at all, of course, but the idea of ES proxies is to be able
to describe anything remotely sane).
No, the global object is the Window, at least per the spec today. Why is
this not accurate?
The current spec calls for the Window to be a proxy-like object, because
that's the only way to implement the spec's indexed getter behavior.
That's not actually compatible with ES because of how "var" needs to
behave in global scope.
Could you elaborate on this?
"var" needs to be able to define non-configurable properties. Proxies
don't necessarily offer useful guarantees about being able to define
such properties on them, and in particular the behavior for index/named
getters in WebIDL precludes definition of non-configurable properties of
the corresponding kind on the relevant object.
So it seems to me that any implementor trying to implement this spec
will go to their favorite ES implementation and discover that the spec
cannot be implemented as written and must instead be mapped to some
other conceptual model. After thinking about it for a bit, the only
obvious way to avoid having proxy-like behavior on the Window is to put
it all on WindowProxy, which _already_ has proxy-like behavior no matter
what.
I don't understand what mapping behaviour you think is conceptually needed
on Window.
I'm not sure what you mean. The "mapping" that needs to happen is "how
do I have a global that's not a magic proxy while being black-box
compatible with the spec?"
I don't think that's a problem, honestly. "length" on a Window returns
the number of child windows. An indexed access on a WindowProxy returns
the corresponding child of its current Window. It seems fairly
straightforward...
Straightforward isn't the word I would use, but ok.
It's a lot more straightforward than what we have now, in terms of
interactions with ES...
Indeed. Of course WindowProxy is already not "just a proxy": it doesn't
transparently proxy enumeration or getOwnPropertyNames, for example.
It should act _exactly_ like Window. As far as I can tell, that means it
_should_ proxy "proxy enumeration" and getOwnPropertyNames, whatever those
are. Why do you think this is not the case?
Because getOwnPropertyNames should return the own properties of the
object, but doing that on a WindowProxy for a cross-origin window should
not in fact return the Window's own properties.
Or another similar issue: getting a property descriptor from a
WindowProxy (for a same-origin window) should probably never claim to
have a non-configurable property, because on navigation the property
will in fact disappear and non-configurable properties are not allowed
to do that in ES. See
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0386.html
and the threads it references. But of course Window is required to be
able to have non-configurable properties (see "var"). So WindowProxy
can't just forward [[GetOwnProperty]] on to the Window.
That link above also talks about how WindowProxy should probably reject
attempts to define non-configurable properties on it altogether, which
is an obvious non-starter for Window because "var" needs to work...
That's just not very clearly specified... Again, I think we should just
clearly define the behavior of WindowProxy using the ES MOP primitives.
I have no idea what that means
How objects behave in ES are defined in terms of various internal
operations. The set of operations ... keeps changing. It used to be
there were [[Get]], [[Set]], etc. Now, with property descriptors, there
are lower-level primitives like [[GetOwnProperty]], [[DefineProperty]],
[[Delete]]. For example, WebIDL defines the behavior of all its objects
in terms of those three primitives. These low-level primitivies and how
they interact define the meta-object protocol (MOP) for the abstract ES
virtual machine.
-Boris
