Allow constructor<ClassType> as a type accepted by functions.

[bfgeek]

From personal email, which I never got around to filing here :)

Something like:

[Constructor]
callback interface Painter {
  static sequence<DOMString> inputProperties;
  void paint(Blah blah);
};

interface PaintWorkletGlobalScope … {
  void registerPaint(DOMString name, constructor<Painter> paintCtor);
};

[domenic]

What does this mean? How would it differ from using Function?

Also, I don't think you want callback interface there...

[bfgeek]

It would mean that we can share a common algorithm for checking the shape of a class constructor, i.e. a constructor version of https://heycam.github.io/webidl/#es-dictionary for example.

At the moment, registerPaint has to do all this itself (incorrectly :) ), would be better if this was a concept in IDL.
https://drafts.css-houdini.org/css-paint-api/#dom-paintworkletglobalscope-registerpaint
This isn't super-high priority as we only have a couple of things at the moment.

At the moment we do it with a Function, then check the shape of the given class.

[bzbarsky]

Checking the shape in what sense? What are you really trying to enforce?

Note that the checks https://drafts.css-houdini.org/css-paint-api/#dom-paintworkletglobalscope-registerpaint does guarantee absolutely nothing, since what they return can change right after registerPaint returns...

[bzbarsky]

I should note also that that spec doesn't really define how inputProperties is operated on in sufficient detail, but that's not relevant to this bug.

[domenic]

If I were to guess what this means it would be doing something like an IsConstructor(f) check, plus a check that f.__proto__ === Painter. It doesn't check that the constructor is actually doing what you want, though: e.g. I could do class X extends Painter { constructor() { return {}; } } and all instances created by X would not be Painters in any way.

[bfgeek]

Yeah, good point maybe spec'ing it this way is a bad idea. Basically this spec was copying webcomponents registerElement (now called define?!?!) substantially:
https://w3c.github.io/webcomponents/spec/custom/#dom-customelementsregistry-define
Which also checks the shape of the constructor passed in.

Writing the same algorithm N times seemed like overkill.

I guess custom elements is different as it explicitly stores the callbacks on define time, then invokes them with the right object?

Re: inputProperties, thanks.

[domenic]

Hmm, I still don't know what you mean by shape. The only thing it checks at this point is IsConstructor.

Later, it does a bunch of checks on the return value of the constructor; see https://w3c.github.io/webcomponents/spec/custom/#dfn-create-element 4.1.3-4.1.10. But I don't see a way to enforce that in the type definition.

[bfgeek]

Steps 11-18 of define function is checking that the prototype has the
correct methods? Again slight different as it then stashes these functions
for use later.
On 24 Mar 2016 2:00 PM, "Domenic Denicola" [email protected] wrote:

Hmm, I still don't know what you mean by shape. The only thing it checks
at this point is IsConstructor.

Later, it does a bunch of checks on the return value of the constructor;
see https://w3c.github.io/webcomponents/spec/custom/#dfn-create-element
4.1.3-4.1.10. But I don't see a way to enforce that in the type definition.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#101 (comment)

[domenic]

Yeah, I wouldn't say it's checking, I would say it's stashing and being sure to throw on invalid values (not undefined, or not a function). And they're not related to the shape (whatever that is) of HTMLElement, since HTMLElement doesn't have any of those methods.

[smaug----]

I think we need to do something here. The current CustomElement and houdini specs are way too JS-y, error prone to maintain and implement.
(1) Looks like current specs using ctors and classes end up taking references to (all? some?) functions when class is passed as a callback. That is at least something which could be done in webidl layer, if it is something we actually want to do.
(2) Other option is to not explicitly store those functions and only just try to use them.

In both cases webidl layer would define what kind of class is expected. (and C++ side of bindings would see that kind of class and could call its methods. If option (2) was used, method call might fail because of the function not being there)