- 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