Specifying QueuingStrategies in WebIDL

[ricea]

As part of #963, we will have to specify CountQueuingStrategy and ByteLengthQueuingStrategy in WebIDL. There are a couple of things about these classes that are "strange" from a WebIDL point-of-view:

1. size() is a function (as opposed to a method), but it is inherited
2. highWaterMark is added by the constructor as a property of the object, rather than coming from the prototype.

I think problem 2. can be fixed quite easily by making highWaterMark a normal interface attribute.

Problem 1. is harder. WebIDL doesn't seem to have functions as such at all. The closest thing is "Callback functions", but it doesn't appear that they can exist as attributes on an interface. There are also "static operations", which are a bit like functions, but appear as properties of the constructor, not the prototype.

[domenic]

I think it's OK to make size() a normal method, although there is some risk of back-compat problems if people are using it in strange ways.

If we think that is not likely to work, we have a few workarounds:

• Use any and return a function object.
• Introduce a new Web IDL extended attribute for methods that removes the brand check.

As always, I apologize for this mess.

[MattiasBuelens]

Would this mean that CountQueuingStrategy.prototype.size() must always be called with a proper CountQueuingStrategy object as this context? Correct me if I'm wrong, but it seems like the WebIDL spec requires a brand check on all operations:

2. If target is an interface, and op is not a static operation:
   2.1. Let esValue be the this value, if it is not null or undefined, or realm’s global object otherwise. (This will subsequently cause a TypeError in a few steps, if the global object does not implement target and [LenientThis] is not specified.)
   2.2. If esValue is a platform object, then perform a security check, passing esValue, id, and "method".
   2.3. If esValue does not implement the interface target, throw a TypeError.

This would be a problem in the current streams specification, since we always call the size algorithm as a plain function with no this context.

[ricea]

I don't want to give up on calling size as a plain function. The principle that it is a pure function is important to the mental model of streams. Making it a method gives the implication that it can be stateful.

The brand check is necessary for the correct functioning of WebIDL-generated code, at least in Blink. Before it can call a C++ method, it needs to make sure it's calling it on an object of the correct type.

The way I'm currently doing it in my in-progress implementation in Blink is this:

[
    Exposed=(Window,Worker,Worklet),
    Constructor(QueuingStrategyInit init)
] interface CountQueuingStrategy {
    readonly attribute any highWaterMark;

    // size is an accessor that returns a function.
    readonly attribute any size;
};

This still has slightly odd semantics:

const size = new CountQueuingStrategy({}).size;
console.assert(size() == 1);

works as expected, but

const size = CountQueuingStrategy.prototype.size;

throws an exception.

[domenic]

For what it's worth, I would prefer to introduce a new Web IDL extended attribute for this, as it's pretty weird to have a getter that returns a function, instead of just having a function directly.

[ricea]

For what it's worth, I would prefer to introduce a new Web IDL extended attribute for this, as it's pretty weird to have a getter that returns a function, instead of just having a function directly.

Yes, an extended attribute would make sense. In C++, the behaviour corresponds to a static method, but in the WebIDL world it's more like a normal method that doesn't take a this value. So perhaps if you annotate an ordinary method like [NoThis] then it would mostly appear like a normal method from JavaScript, but the bindings code would translate it to a call to a static method in C++.