Ticket #11 (new feature)

Opened 2 years ago

Last modified 1 year ago

An object used on the right of the in operator may fail to be compatible with ContainerType

Reported by: brendan Assigned to: brendan
Type: feature Priority: major
Milestone: M1 Component: Spec
Version: 4 Keywords:
Cc:

Description

As with the iteration_protocol, an object used on the right of the in operator may fail to be compatible with this type (ContainerType?). Mutable prototypes make it easy to break core language semantics. This is true to some extent in ES1-3, e.g. by overriding Object.prototype.toString or Object.prototype.hasOwnProperty. One way to enforce default semantics would be to say that if the right operand of in is incompatible with iterator::ContainerType?, then in defaults to ES3 semantics. But if we say this, there is no point in defining Object.prototype.contains.

The same argument could be made, as noted above re: Python’s iter probing, for the case where a for-in loop head’s right operand is incompatible with iterator::IterableType?.

Wiki location => proposals:iterators_and_generators

Attachments

Change History

Changed 2 years ago by brendan

  • owner set to brendan

Changed 2 years ago by brendan

  • milestone changed from M0 to M1

Changed 1 year ago by lth

  • component changed from Proposals to Spec

Changed 1 year ago by lth

Ticket needs clarification.

Changed 1 year ago by brendan

Ok, I recall Lars caring about this a while ago, but I may have a better argument now:

The iterators and generators proposal specifies protocols for iteration, enumeration, and itemization based on new iterator::get, etc. names for properties in the object being iterated by for-in forms, or contains-tested via in. To preserve default ES3 behavior, the proposal defines DontEnum properties in Object.prototype for these new hooks.

But what if someone deletes those Object.prototype properties? Should for-in and in break? Or should all implementations be required to suppress the structural type test failure and fall back on the default hooks?

If the latter, which seems wise to me, then there is no need for the DontEnum props in Object.prototype. They complicate the spec and require mutation and attribute bit fiddling. Why not simplify and specify *only* fallback on default in case of any structural type test failure?

/be

Note: See TracTickets for help on using tickets.