Referencing "implements"

[annevk]

Specifications may reference the concept "|object| implements |interface|"
in various ways, including "|object| is an |interface| object".

Can we try to settle on the one true way that we iterate towards as we make specifications link this concept?

I'm happy to convert DOM, but I'd prefer doing it just the once.

(Apologies for not catching this sooner. But also, thanks a lot for landing that patch, it's great that we finally have formal brand checks.)

[Ms2ger]

Sure, I'm happy to go whichever way here.

[annevk]

I cannot really use this. Whenever we operate on algorithms they're no longer ECMAScript values. I need the equivalent check for IDL values. I suspect this applies to all specifications that use IDL. Or do we expect specifications to say something like:

If node's corresponding ECMAScript value implements Text, then ...

?

It seems IDL could maybe use something similar to assert that a specification algorithm returns a thing compatible with the IDL fragment?

(It might be nice if IDL values were standardized a bit more so "corresponding ECMAScript value" was a defined term too.)

[Ms2ger]

That's a fair point. Maybe we could use "is a Text object" for IDL values, and use "implements" for JS values? I think using "corresponding ECMAScript value" would generally be a sign of bad layering; in the few cases that need it, I'd consider using https://heycam.github.io/webidl/#interface-to-es.

[domenic]

I'd caution against "is an X object" because then we get into the confusing situations that we see in whatwg/dom#719. "is a Text object" implies to me it is not a CharacterData object. "implements" is a little better, I guess.

(Personally I think this is really an issue with DOM favoring consistency over clarity, but I've given up on that argument.)

[littledan]

From your description, it sounds like DOM is already using the meaning that we would be hoping for here. Am I missing something? I like the "is an X object" phrasing since it is simple and already widespread.

[domenic]

The problem is, when you (or at least I) read DOM and see the following list:

• Do X when node is a Document object
• Do Y when node is a DocumentType object
• Do Z when node is an Attr object
• Do W when node is a Comment or Text object
• Do Q when node is a ProcessingInstruction object
• Do R when node is anything else

(e.g., in https://dom.spec.whatwg.org/#concept-node-clone) it's extremely easy to miss that "is a Comment or Text object" actually means "is a Comment or Text or CDATASection object".

We have had multiple cases where we missed this while implementing the corresponding algorithms in jsdom, e.g. jsdom/jsdom@b5f92d5 or jsdom/jsdom@c96decf#diff-a824c999a718befbc63cedf412e05560

[annevk]

I'm leaning toward using "implements" in the DOM Standard, but I see there is still the slight problem of it only being defined for ECMAScript values, not IDL objects. I think I'll ignore that issue for now though and assume we'll eventually make it work for either (or allow them to be magically swapped as needed).

[annevk]

I meant to keep this open as there is still the ECMAScript vs IDL value problem. (The DOM now uses "implements" upon IDL values.)