search

whatwg / webidl

Web IDL Standard
https://webidl.spec.whatwg.org/
Other
405 stars 162 forks source link

Referencing "implements" #659

Open annevk opened 5 years ago

annevk commented 5 years ago

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 commented 5 years ago

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

annevk commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

I'd caution against "is an X object" because then we get into the confusing situations that we see in https://github.com/whatwg/dom/issues/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 commented 5 years ago

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 commented 5 years ago

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

(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. https://github.com/jsdom/jsdom/commit/b5f92d5bc16339f34562f13be8e74b5148014d66 or https://github.com/jsdom/jsdom/commit/c96decf837ece54bdc550dfb7dca7e5d6c97bc2d#diff-a824c999a718befbc63cedf412e05560

annevk commented 3 years ago

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 commented 3 years ago

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