Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tighten up [Serializable] and [Transferable] definitions #5036

Merged
merged 2 commits into from
Oct 25, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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