From 7120e0fee022b1eeb307c561993f46bd56b7338a Mon Sep 17 00:00:00 2001 From: Domenic Denicola Date: Wed, 23 Oct 2019 14:48:34 -0400 Subject: [PATCH 1/2] Tighten up [Serializable] and [Transferable] definitions * Prohibits use on interfaces involving inheritance, since we weren't handling that. * Removes the attempt at supporting mixins. Mixins have changed, so the text was no longer correct, and it was never very complete anyway. --- source | 40 +++++++++++++++++++++++----------------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/source b/source index 27d7dafff7e..cdb90ab52d0 100644 --- a/source +++ b/source @@ -8061,7 +8061,7 @@ interface DOMStringList { serializable objects are necessarily preserved when they are serialized.

Platform objects can be serializable objects - if they implement only interfaces decorated with the primary interface is decorated with the [Serializable] IDL extended attribute. Such interfaces must also define the following algorithms:

@@ -8105,12 +8105,15 @@ interface DOMStringList { and deserialized by these steps. Typically the steps are very symmetric.

The [Serializable] extended attribute must take no - arguments, and must not appear on anything other than an interface. It must appear only once on an - interface. It must not be used on a callback interface. If it appears on a partial interface or an - interface that is really a mixin, then it must also appear on the original or mixed-in-to - interface, and any supplied serialization steps and deserialization - steps for the partial interface or mixin should be understood as being appended to those of - the original or mixed-in-to interface.

+ arguments, and must only appear on an interface. It must not appear on an interface that inherits + from another interface, or an interface which is inherited from by another interface. It must not + appear more than once on an interface.

+ +

We could extend [Serializable] to work on + interfaces involving inheritance, or on interface mixins, or for partial interfaces. For now, it + remains restricted since this complexity hasn't been necessary. Please file an issue if you have a use case for + adding serialization behavior to these constructs.

Let's say we were defining a platform object Person, which had @@ -8178,7 +8181,7 @@ interface DOMStringList { been transferred, it cannot be transferred, or indeed used, again.

Platform objects can be transferable objects - if they implement only interfaces decorated with the primary interface is decorated with the [Transferable] IDL extended attribute. Such interfaces must also define the following algorithms:

@@ -8210,12 +8213,15 @@ interface DOMStringList { by these steps. Typically the steps are very symmetric.

The [Transferable] extended attribute must take no - arguments, and must not appear on anything other than an interface. It must appear only once on an - interface. It must not be used on a callback interface. If it appears on a partial interface or an - interface that is really a mixin, then it must also appear on the original or mixed-in-to - interface, and any supplied transfer steps and transfer-receiving - steps for the partial interface or mixin should be understood as being appended to those of - the original or mixed-in-to interface.

+ arguments, and must only appear on an interface. It must not appear on an interface that inherits + from another interface, or an interface which is inherited from by another interface. It must not + appear more than once on an interface.

+ +

As with [Serializable], we could extend [Transferable] to work on interfaces involving inheritance, or on + interface mixins, or for partial interfaces. For now, it remains restricted since this complexity + hasn't been necessary. Please file an + issue if you have a use case for adding transferring behavior to these constructs.

Platform objects that are transferable objects have a DOMStringList {

  • Otherwise, if value is a platform object that is a serializable object, then perform the appropriate - serialization steps given value, serialized, and - forStorage.

    + data-x="serializable objects">serializable object, then perform the serialization + steps for value's primary interface, given value, + serialized, and forStorage.

    The serialization steps may need to perform a sub-serialization. This is an operation which takes as input a value From dbd8dc22c1969d4cf7a04996967e62c512386b32 Mon Sep 17 00:00:00 2001 From: Domenic Denicola Date: Thu, 24 Oct 2019 12:36:47 -0400 Subject: [PATCH 2/2] Allow inheritance after all --- source | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/source b/source index cdb90ab52d0..9fe14f26fae 100644 --- a/source +++ b/source @@ -8105,15 +8105,15 @@ interface DOMStringList { and deserialized by these steps. Typically the steps are very symmetric.

    The [Serializable] extended attribute must take no - arguments, and must only appear on an interface. It must not appear on an interface that inherits - from another interface, or an interface which is inherited from by another interface. It must not - appear more than once on an interface.

    + arguments, and must only appear on an interface. It must not appear more than once on an + interface.

    -

    We could extend [Serializable] to work on - interfaces involving inheritance, or on interface mixins, or for partial interfaces. For now, it - remains restricted since this complexity hasn't been necessary. Please file an issue if you have a use case for - adding serialization behavior to these constructs.

    +

    For a given platform object, only the object's primary interface is + considered during the (de)serialization process. Thus, if inheritance is involved in defining the + interface, each [Serializable]-annotated interface in the + inheritance chain needs to define standalone serialization steps and + deserialization steps, including taking into account any important data that might + come from inherited interfaces.

    Let's say we were defining a platform object Person, which had @@ -8213,15 +8213,15 @@ interface DOMStringList { by these steps. Typically the steps are very symmetric.

    The [Transferable] extended attribute must take no - arguments, and must only appear on an interface. It must not appear on an interface that inherits - from another interface, or an interface which is inherited from by another interface. It must not - appear more than once on an interface.

    - -

    As with [Serializable], we could extend [Transferable] to work on interfaces involving inheritance, or on - interface mixins, or for partial interfaces. For now, it remains restricted since this complexity - hasn't been necessary. Please file an - issue if you have a use case for adding transferring behavior to these constructs.

    + arguments, and must only appear on an interface. It must not appear more than once on an + interface.

    + +

    For a given platform object, only the object's primary interface is + considered during the transferring process. Thus, if inheritance is involved in defining the + interface, each [Transferable]-annotated interface in the + inheritance chain needs to define standalone transfer steps and + transfer-receiving steps, including taking into account any important data that might + come from inherited interfaces.

    Platform objects that are transferable objects have a