lexical for-in/for-of loose end

Herby Vojčík herby at mailbox.sk
Fri Feb 3 02:28:50 PST 2012

Allen Wirfs-Brock wrote:
> On Feb 2, 2012, at 1:38 PM, Brendan Eich wrote:
>> keys etc. are currently spec'ed to to do own-only, you want allKeys to
>> do the crazy thing:
>> http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api
>> Let's not go around and around on this. Enumerable proto-properties
>> are harmful, no one wants them.
> I'm afraid I have to disagree with the absolutism of this statement.
> There are some perfectly reasonable use cases for enumerating proto
> properties and they are quite in alignment with prototypal inheritance.
> For example, how about defining a set of default property values and
> then using prototypal inheritance to selective over-ride them:
> let privateImplicitOptions = {a:1,b:2,c:3 /* and on and on */};
> function makeOptions(explicitOptions) {
> let opt = Object.create(privateImplicitOptions);
> for (let [k.,v] of items(explicitOptions)) opt[k]=v;
> return opt;
> }
> myOpts = makeOptions({b:-2});
> Why should somebody I pass an options object to need to worry about
> whether I used zero, one, or n levels of prototypes to represent by options.


> that said, I think we agree that the real problem is the legacy ES
> semantics of for-in and its use (or lack of) for the enumerable
> attribute. If we can start out with a clean slate conceptual slate for
> for-of maybe we don't have to worry about such things. However, carrying
> over a lot of historic baggage isn't a clean slate. Thinking in terms of
> abstract collections, having keys() not mean "all keys in the
> collection" seems quite absurd. That should be the normal case, the more
> verbose name should be used for the exceptional case that excludes some
> of the keys. Now in this case, the real problem is in deciding the
> default way to view a plain Es objects as an abstract collection. Maybe
> only considering own properties as the collection elements is the right
> thing. In that case it may be "allKeys" that is carrying the wrong
> implication and instead it should be something like "extendedKeys".

deepKeys, maybe?

> Allen


More information about the es-discuss mailing list