Re: [heycam/webidl] Update method creation for operations (#155)

> +                            not the appropriate global object.)
> +
> +                            <!-- https://www.w3.org/Bugs/Public/show_bug.cgi?id=18547#c9 -->
> +                          </li>
> +
> +                          <li>Otherwise, set <var>O</var> to the <span class='esvalue'>this</span>
> +                          value.</li>
> +
> +                          <li>If <var>O</var> is a <a class='dfnref'
> +                          href='#dfn-platform-object'>platform object</a>, then <a class='dfnref'
> +                          href='#dfn-perform-a-security-check'>perform a security check</a>,
> +                          passing <var>O</var>, <var>realm</var>, <var>id</var>, and "method".</li>
> +
> +                          <li>If <var>O</var> is not a <a class='dfnref'
> +                          href='#dfn-platform-object'>platform object</a> that implements the
> +                          interface <var>target</var>, <a href='#ecmascript-throw' class='dfnref

Yeah, I agree this stuff is all broken right now.  :(  Good catch on the unforgeable operations bit.

The reason things are complicated in terms of the current definitions is that the current spec technically allows this, afaict:

    [Constructor] interface Foo {
    };
    [Constructor] interface Bar {
      void something();
    };
    Foo implements Bar;

And then script can do:

    var foo = new Foo(); // proto is Foo.prototype, which has own prop named "something"
    var bar = new Bar(); // proto is Bar.prototype, which has own prop named "something"
    console.log(foo.something == bar.something); // logs false

but the spec's model of this is pretty iffy.  For example, I think in the spec's model there is only one operation here, but it's exposed on two different interfaces and there are two different JS functions involved which do different brand checks.  Or something.  And just talking about "supplemental interface" is not useful, since in my example `Bar` is supplemental for `foo` but not for `bar`.

In practice the right way to address this is to make the instance and interface and interface prototype object setups more imperative.  Then the imperative algorithm will know which non-supplemental interface is causing the property to exist and will be able to pass that information into the "create a function" algorithm...

The other thing that would make all this clearer, of course, is making mixins different syntactically and outlawing my example above; it would have to become something like:

    [Constructor] interface Foo {
    };
    [Constructor] interface Bar {
    };
    mixin FooBarMixin {
      void something();
    };
    Foo implements FooBarMixin;
    Bar implements FooBarMixin;

> There is no "the" interface whose interface prototype object is Navigator.prototype

Well, there is.  It's called `Navigator`.  ;)

> Otherwise the previous step, which says "Otherwise, the property exists solely on the interface’s interface prototype object" would not work at all for NavigatorID.

This wording I agree is broken.  Maybe what we should do in the short term is redefine "interface members" (currently a purely syntactic definition) to be "the things syntactically in this interface, plus the things syntactically in its consequential interfaces".  Then the Navigator interface will have all the bits from NavigatorID in its "interface members" and things will work.  Or, depending on what other things use "interface members" we could define a new term that means the new thing and use it in the http://heycam.github.io/webidl/#es-operations setup to make sure we see all the relevant operations while using Navigator for their brand checks, which is what we want....

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/155/files/5f3f6f66bb2d8cfbf1c7197e64f2b54f9cdd2845#r77409685