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.

Sign up for GitHub

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

Jump to bottom

Define [[OwnPropertyKeys]] of legacy platform objects #402

Merged
merged 2 commits into from Aug 12, 2017
Merged

Define [[OwnPropertyKeys]] of legacy platform objects #402

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6c2ceed
Define [[OwnPropertyKeys]] of legacy platform objects
TimothyGu Aug 7, 2017
ef6832d
fixup! update blurb per Tobie
TimothyGu Aug 8, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
44 changes: 25 additions & 19 deletions index.bs
View file
Open in desktop
Expand Up @@ -8516,7 +8516,7 @@ If the [{{LegacyUnenumerableNamedProperties}}]
extended attribute is specified on an interface, then it applies to all its derived interfaces and
must not be specified on any of them.

See [[#legacy-platform-object-property-enumeration]]
See [[#legacy-platform-object-getownproperty]]
for the specific requirements that the use of
[{{LegacyUnenumerableNamedProperties}}]
entails.
Expand Down Expand Up @@ -12005,28 +12005,34 @@ and [[#legacy-platform-object-set]].
</div>


<h4 id="legacy-platform-object-property-enumeration" oldids="property-enumeration">Property enumeration</h4>
<h4 id="legacy-platform-object-ownpropertykeys" oldids="property-enumeration,legacy-platform-object-property-enumeration">\[[OwnPropertyKeys]]</h4>

This document does not define a complete property enumeration order
for [=platform objects=] implementing [=interfaces=]
(or for <a href="#es-exception-objects">platform objects representing exceptions</a>).
However, for [=legacy platform objects=],
properties on the object must be
enumerated in the following order:

1. If the object [=support indexed properties|supports indexed properties=], then
the object’s [=supported property indices=] are
enumerated first, in numerical order.
1. If the object [=support named properties|supports named properties=] and doesn't implement an [=interface=] with the
[{{LegacyUnenumerableNamedProperties}}]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The effects of the [{{LegacyUnenumerableNamedProperties}}] extended attribute seem totally gone from the updated algorithm. Is that on purpose?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, LegacyUnenumerableNamedProperties controls the enumerable bit in the descriptor but not the existence of the key. See [[GetOwnProperty]]. The original pseudo-algorithm defines the "enumeration order", basically the order of for-in loops, which accounts for both enumerability and key existence.

[=extended attribute=], then
the object’s [=supported property names=] that
are visible according to the [=named property visibility algorithm=]
are enumerated next, in the order given in the definition of the set of supported property names.
1. Finally, any enumerable own properties or properties from the object’s prototype chain are then enumerated,
in no defined order.

Note: Future versions of the ECMAScript specification may define a total order for property enumeration.
However, it does for [=legacy platform objects=] by defining the \[[OwnPropertyKeys]]
internal method as follows.

<div algorithm="to invoke the internal [[OwnPropertyKeys]] method of legacy platform objects">

When the \[[OwnPropertyKeys]] internal method of a [=legacy platform object=] |O| is called,
the following steps are taken:

1. Let |keys| be a new empty [=list=] of ECMAScript String and Symbol values.
1. If |O| [=support indexed properties|supports indexed properties=], then [=list|for each=] |index| of |O|’s
[=supported property indices=], in ascending numerical order, [=list|append=] [=!=] [=ToString=](|index|) to
|keys|.
1. If |O| [=support named properties|supports named properties=], then [=list|for each=] |P| of |O|’s
[=supported property names=] that is visible according to the [=named property visibility algorithm=],
[=list|append=] |P| to |keys|.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these also in ascending chronological order?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The order is defined by the specification for the specific interface.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, right. That's the order in which they're spec'ed. In one of the toJSON-related algorithms we write this as:

If a toJSON operation with a [Default] extended attribute is declared on |I|,
then for each exposed regular attribute |attr| that is an interface member of |I|,
in order:

Maybe just add in order, before [=list|append=] |P| to |keys|?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"for each" from Infra already defines the order so you don't have to add that kind of thing. (At least, iirc that's the idea.)

Copy link
Collaborator

@tobie tobie Aug 7, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@annevk, you're right. I'd just like to be a little more explicit in both those cases that enumeration order follows the order in which the attributes are specified in the interface. But we can leave that out for now and fix them up both together later if necessary.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally mixed up a bunch of things here. Apologies for muddling the conversation. Please ignore this comment altogether.

1. [=list|For each=] |P| of |O|’s own property keys that is a String, in ascending chronological order of
property creation, [=list|append=] |P| to |keys|.
1. [=list|For each=] |P| of |O|’s own property keys that is a Symbol, in ascending chronological order of
property creation, [=list|append=] |P| to |keys|.
1. Assert: |keys| has no duplicate items.
Copy link
Collaborator

@tobie tobie Aug 7, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not used an ordered list instead (as you initially suggested)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Assuming you meant ordered set...) ES uses a plain List, and it would actually be a specification error if there are duplicates, since the named property visibility algorithm should filter out any supported property names that are also own properties on the object (or in its prototype chain).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Assuming you meant ordered set...)

I did. :)

ES uses a plain List, and it would actually be a specification error if there are duplicates, since the named property visibility algorithm should filter out any supported property names that are also own properties on the object (or in its prototype chain).

That makes sense.

1. Return |keys|.

</div>

<h4 id="legacy-platform-object-abstract-ops">Abstract operations</h4>

Expand Down