Skip to content

Commit

Permalink
Tighten up [Serializable] and [Transferable] definitions
Browse files Browse the repository at this point in the history
* Spells out how when interitance gets involved, specs need to handle
  the whole object; we don't do any automatic
  inheritance-chain-crawling.
* Removes the attempt at supporting mixins. Mixins have changed, so the
  text was no longer correct, and it was never very complete anyway.
  • Loading branch information
domenic authored and annevk committed Oct 25, 2019
1 parent c912846 commit 3f3b8c2
Showing 1 changed file with 23 additions and 17 deletions.
40 changes: 23 additions & 17 deletions source
Original file line number Diff line number Diff line change
Expand Up @@ -8061,7 +8061,7 @@ interface <dfn>DOMStringList</dfn> {
<span>serializable objects</span> are necessarily preserved when they are serialized.</p>

<p><span data-x="platform object">Platform objects</span> can be <span>serializable objects</span>
if they implement only interfaces decorated with the <dfn data-export=""
if their <span>primary interface</span> is decorated with the <dfn data-export=""
data-dfn-type="extended-attribute" data-lt="Serializable"
data-x="Serializable"><code>[Serializable]</code></dfn> IDL <span>extended attribute</span>. Such
interfaces must also define the following algorithms:</p>
Expand Down Expand Up @@ -8105,12 +8105,15 @@ interface <dfn>DOMStringList</dfn> {
and deserialized by these steps. Typically the steps are very symmetric.</p>

<p>The <code data-x="Serializable">[Serializable]</code> 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 <span>serialization steps</span> and <span>deserialization
steps</span> for the partial interface or mixin should be understood as being appended to those of
the original or mixed-in-to interface.</p>
arguments, and must only appear on an interface. It must not appear more than once on an
interface.</p>

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

<div class="example">
<p>Let's say we were defining a platform object <code data-x="">Person</code>, which had
Expand Down Expand Up @@ -8178,7 +8181,7 @@ interface <dfn>DOMStringList</dfn> {
been transferred, it cannot be transferred, or indeed used, again.</p>

<p><span data-x="platform object">Platform objects</span> can be <span>transferable objects</span>
if they implement only interfaces decorated with the <dfn data-export=""
if their <span>primary interface</span> is decorated with the <dfn data-export=""
data-dfn-type="extended-attribute" data-lt="Transferable"
data-x="Transferable"><code>[Transferable]</code></dfn> IDL <span>extended attribute</span>. Such
interfaces must also define the following algorithms:</p>
Expand Down Expand Up @@ -8210,12 +8213,15 @@ interface <dfn>DOMStringList</dfn> {
by these steps. Typically the steps are very symmetric.</p>

<p>The <code data-x="Transferable">[Transferable]</code> 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 <span>transfer steps</span> and <span>transfer-receiving
steps</span> for the partial interface or mixin should be understood as being appended to those of
the original or mixed-in-to interface.</p>
arguments, and must only appear on an interface. It must not appear more than once on an
interface.</p>

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

<p><span data-x="platform object">Platform objects</span> that are <span>transferable
objects</span> have a <dfn data-export="" data-dfn-for="platform object"
Expand Down Expand Up @@ -8578,9 +8584,9 @@ interface <dfn>DOMStringList</dfn> {

<li>
<p>Otherwise, if <var>value</var> is a <span>platform object</span> that is a <span
data-x="serializable objects">serializable object</span>, then perform the appropriate
<span>serialization steps</span> given <var>value</var>, <var>serialized</var>, and
<var>forStorage</var>.</p>
data-x="serializable objects">serializable object</span>, then perform the <span>serialization
steps</span> for <var>value</var>'s <span>primary interface</span>, given <var>value</var>,
<var>serialized</var>, and <var>forStorage</var>.</p>

<p>The <span>serialization steps</span> may need to perform a <dfn
data-export="">sub-serialization</dfn>. This is an operation which takes as input a value
Expand Down

0 comments on commit 3f3b8c2

Please sign in to comment.