[Clonable] and [Transferable] attributes for WebIDL interfaces #1162
Labels
clarification
Standard could be clearer
Comments
|
Since these would not have any normative requirements, I don't think this is a good idea. (That is: cloneability and transferability is already defined by the presence of the object in the StructuredClone algorithm, or by the presence of a [[Transfer]] internal method.) These annotations would easily get out of sync with the actual normative spec, and cause confusion. |
|
I guess [Transferable] at least could cause the creation of a [[Detached]] internal slot. I suppose [Cloneable] would mean that it has a non-default [[Clone]], similar to [Constructor]. I think there's also some value in having the class structure described in IDL as you can figure out many aspects of an object in a single view. |
alice
pushed a commit
to alice/html
that referenced
this issue
Jan 8, 2019
This rewrites most of the cloneable and transferable object infrastructure to better reflect the reality that structured cloning requires separate serialization and deserialization steps, instead of a single operation that creates a new object in the target Realm. This is most evident in the case of MessagePorts, as noted in whatwg#2277. It also allows us to avoid awkward double-cloning with an intermediate "user-agent defined Realm", as seen in e.g. history.state or IndexedB; instead we can simply store the serialized form and later deserialize. Concretely, this: * Replaces the concept of cloneable objects with serializable objects. For platform objects, instead of defining a [[Clone]]() internal method, serializable platform objects are annotated with the new [Serializable] IDL attribute, and include serialization and deserialization steps in their definition. * Updates the concept of transferable objects. For platform objects, instead of defining a [[Transfer]]() internal method, transferable platform objects are annotated with the new [Transferable] IDL attribute, and include transfer and transfer-receiving steps. Additionally, the [[Detached]] internal slot for such objects is now managed more automatically. * Removes the StructuredClone() abstract operation in favor of separate StructuredSerialize() and StructuredDeserialize() abstract operations. In practice we found that performing a structured clone alone is never necessary in specs. It is always either coupled with a transfer list, for which StructuredCloneWithTransfer() can be used, or it is best expressed as separate serialization and deserialization steps. * Removes IsTransferable() and Transfer() abstract operations. When defined more properly, these became less useful by themselves, so they were inlined into the rest of the machinery. * Introduces StructuredSerialzieWithTransfer() and StructuredDeserializeWithTransfer(), which can be used by other specifications which need to define their own postMessage()-style algorithm but for which StructuredCloneWithTransfer() is not sufficient. Closes whatwg#785. Closes whatwg#935. Closes whatwg#2277. Closes whatwg#1162. Sets the stage for whatwg#936 and whatwg#2260/whatwg#2361.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we support the cloning and the transferring of many DOM objects, but there is not a well defined list of such elements. I propose to mark the webIDL interfaces of them with [Clonable] and [Transferable].
This can be also useful to do a unified validation of the {window, workers, MessagePort, BroadcastChannel}.postMessage(s) arguments.
The text was updated successfully, but these errors were encountered: