Add [[PlatformBrand]] internal slot to all platform objects #97
Comments
This is basically the introduction of ShadowRoot objects as a node in the DOM Standard. The plan is to port over the features over time, while trying to make sure the new features and terminology remain consistent and coherent with the rest of the standard. I’ll try to prefix ShadowRoot-object-related commits with “Shadow”.
tobie
added
enhancement
⌛⌛ duration:medium
|
Is the [[PlatfromBrand]] on the instance (for example a text node in the DOM, not the Text interface or Text interface prototype object?) For what it is worth Blink implements the check for HTMLElement in custom elements as if the brand is on the instance; see CustomElementDefinition::checkConstructorResult. Sorry for the C++, but basically it checks the element instance is a HTMLElement; it doesn't consult JavaScript prototypes or anything. |
|
Yes, on the instance. All internal slots are I think. |
|
(Once we add this StructuredSerialize can be simplified a little bit as all platform objects will have this slot and therefore can be treated like promises or WeakMap objects.) |
|
The other thing that would be useful here is some shorthands around it. When you check against the list of platform brands, there's a difference if the matched value is first in the list or somewhere else (or last and somewhere else, depending on order). E.g., in DOM we sometimes want to match DocumentFragment, but not ShadowRoot (a subclass). |
|
It sounds like we'd have two "entrypoints" to
Is that what you were picturing, @annevk? The first one will be pretty easy to update, but the second would be a lot of work to go around fixing up. Would it be reasonable to add a "create a new platform object of interface |interface|" algorithm to WebIDL and update all the other specs to call into that? |
- Define an imperative algorithm for instantiating a platform object, which everything theoretically calls into, and which sets the primary interface into a new internal slot [[PrimaryInterface]]. - Define the "implements" algorithm as checking the [[PrimaryInterface]] internal slot. This PR procrastinates on defining an imperative algorithm for [Global] interfaces, which would be a bit more text. Fixes whatwg#97
- Define an imperative algorithm for instantiating a platform object, which everything theoretically calls into, and which sets the primary interface into a new internal slot [[PrimaryInterface]]. - Define the "implements" algorithm as checking the [[PrimaryInterface]] internal slot. The algorithm here is roughly in correspondence with the V8 implementation, where operation functions are allocated with a reference to a FunctionTemplate object (which is in corresondence with WebIDL interfaces). When checking the receiver of a method that came from WebIDL, the original prototype chain is traversed by looking at the FunctionTemplate's parent. The same FunctionTemplate is used in multiple JavaScript realms. This PR procrastinates on defining an imperative algorithm for [Global] interfaces, which would be a bit more text. It also doesn't define which global object is associated with platform objects, or how this association is represented. Fixes whatwg#97
|
Yeah, I think that's reasonable. We also want "x is a XYZ" formalized as a shorthand for "is a platform object that implements" for use in other standards. I'm not a 100% sure
is true anymore btw. I kinda hope it's not. |
- Update the steps for instantiating a platform object, which everything theoretically calls into, and which sets the primary interface into a new internal slot [[PrimaryInterface]]. - Define the "implements" algorithm as checking the [[PrimaryInterface]] internal slot. The algorithm here is roughly in correspondence with the V8 implementation, where operation functions are allocated with a reference to a FunctionTemplate object (which is in corresondence with WebIDL interfaces). When checking the receiver of a method that came from WebIDL, the original prototype chain is traversed by looking at the FunctionTemplate's parent. The same FunctionTemplate is used in multiple JavaScript realms. Fixes #97.
- Update the steps for instantiating a platform object, which everything theoretically calls into, and which sets the primary interface into a new internal slot [[PrimaryInterface]]. - Define the "implements" algorithm as checking the [[PrimaryInterface]] internal slot. The algorithm here is roughly in correspondence with the V8 implementation, where operation functions are allocated with a reference to a FunctionTemplate object (which is in corresondence with WebIDL interfaces). When checking the receiver of a method that came from WebIDL, the original prototype chain is traversed by looking at the FunctionTemplate's parent. The same FunctionTemplate is used in multiple JavaScript realms. Fixes #97.
The [[PlatformBrand]] internal slot would be a List (in the ECMAScript sense) of strings. One string per interface on the interface chain of the object. So e.g., Text would have "Text, "CharacterData", "Node", "EventTarget".
This would allow us to be more specific what we mean with instances of something and would also clear up a lot of language in IDL I think.
The text was updated successfully, but these errors were encountered: