2012/11/25 Brendan Eich <[email protected]> > David Bruant wrote: > >> Here is an idea to uniformize the enumeration story while removing >> enumeration inconsistency footgun. I'll describe it in proxy trap terms. A >> unique trap (or internal operation) > > keyEnumerate: () -> iterator for {propertyKey, enumerable} >> There is this unique operation which returns an iterator not for property >> keys, but for an object containing a property key and a boolean signifying >> the enumerable boolean. >> Using this, each userland operation would use this iterator, drain it out >> (unless the iteration is being aborted like by throwing in a for-in loop) >> and filter out based on the exact userland operation so that: >> * All would filter out if propertyKey is ever a private symbol >> * Object.getOwnPropertyNames would keep all other property keys >> regardless of the enumerable value >> * Object.keys would filter out properties which are described as >> non-enumerable >> * for-in would filter out non-enumerable and retrieve the different >> keyEnumerate from the prototype chain objects. >> With this unique internal operation, an object is able to communicate its >> intent regarding what's enumerated and each enumeration userland operation >> only keeps what it's interested in. >> > > As an internal method architecture for the spec, this seems fine -- the > "object" returned cannot be observed and could be an internal type, a la > Reference. > > For a proxy trap, this seems too low-level and the overhead (without > optimization to look into the continuation for a destructuring pattern and > avoid the object allocation) is again a potential problem. Tom should weigh > in.
I'm not too worried about inconsistencies between traps. I don't see it as sufficient reason to refactor the current getOwnPropertyNames/keys/enumerate trap design. Of course I'm open to alternatives if people think it is a major issue. > and there was no Reflect.setPrototypeOf operation in the harmony Reflect >> module proposal on purpose so that 'delete Object.prototype.__proto__' at >> any point would be enough to be sure that all [[Prototype]]-setting >> capabilities are removed. >> So I think the Reflect.setPrototypeOf should be removed. >> > > Yes, we covered this on-list extensively. There should be no > *.setPrototypeOf function anywhere. I agree. I don't think we want Reflect.setPrototypeOf. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
