- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Thu, 26 Feb 2015 17:40:07 -0500
- To: Domenic Denicola <d@domenic.me>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 2/26/15 5:35 PM, Domenic Denicola wrote:
> Having thought about this for a bit, I think it is not different. If you picture the beginning of every WebIDL method as beginning with
>
> const thisToUse = this === undefined ? window : this;
> if (!brandCheck(this, <<interfaceSpecificBrandHere>>)) { throw new TypeError(); }
>
> then all the cases except methods on Window/objects in Window's prototype chain will just fail the second line if the first line coerces undefined to window.
Right. I mean, it might affect the exception thrown, but a UA could in
fact adjust that (e.g. if the branch check fails check the "this" and if
it was undefined throw "this is not an object" instead of "this is not a
Foo".
> The only exceptions I can think of are maybe [LenientThis], and any WebIDL methods that don't happen to check branding, which I am not sure is possible.
There aren't any Web IDL methods that don't check branding.
[LenientThis] only has an effect on attributes, and attribute
getters/setters obviously don't need to do the [ImplicitThis]-like
behavior; the only way to invoke one of those with an undefined "this"
is by manually getting the getter/setter and then .call()/.apply()-ing
it, and I'm totally cool with that just throwing in the
non-[LenientThis] case. ;)
-Boris
Received on Thursday, 26 February 2015 22:40:37 UTC