W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2012

RE: Question about implements statements

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Mon, 18 Jun 2012 22:56:30 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B383839BC9B@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> > On 6/15/12 6:24 PM, Travis Leithead wrote:
> > First of all, changing an instance's internal prototype is not legit ECMAScript.
> Yes, yes.  But I didn't remember the property descriptor boilerplate offhand.  The
> effect is the same.
> > Beyond that, the getter (or setter) always has to validate the "this"
> > value whenever it is invoked because you can always "bind" or "call"
> > the method with _any_ this value.
> Yes, of course.  The question is what values of "this" should be valid for web
> APIs.
> > Off topic: Usually interfaces that are right-hand-side targets for the
> > implements statement Are marked with [NoInterfaceObject] so that you
> > don't typically see this problem
> That doesn't help in my example.  Setting C as [NoInterfaceObject] does not
> prevent someone from grabbing a getter from an instance of A and calling it on
> an instance of B.  The question is whether that should throw or "work".  The
> spec right now is somewhere between ambiguous and "work".  I would prefer
> that it said "throw".

It seems to me, that an implementer must keep track of which API sets get mixed-in to what objects, and configure the "this" validator of each API to only accept instances that match those target objects. Everything else must throw.

As a spec author, if I mix in some set of functionality onto my new interface, I expect that those APIs that I mixed in will work with instances of my new object. Implementers have to ensure that happens correctly.

> -Boris
Received on Monday, 18 June 2012 22:57:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:06 UTC