lexical for-in/for-of loose end

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Feb 1 18:17:17 PST 2012


On Feb 1, 2012, at 3:31 PM, Brendan Eich wrote:

> Brendan Eich wrote:
>> It's never inconsistent to allow one thing and disallow another. The particulars matter. This isn't "anything goes". Destructuring has a bit of utility and a lot of regularity in for-in head position. The initialiser from VariableDeclarationNoIn has neither specific utility nor regularity with respect to for-in in AWK, Python, or any other language with such a construct. 
> 
> More to say, I sent too soon. Don't take this as more than it is: an attempt to explore an alternative meaning of for-in combined with certain destructuring patterns.
> 
> We have a request that seemed to receive popular support, to support
> 
>  for own (k in o) ...;
> 
> This could compose with the following nicely, and it tries to pave the CoffeeScript cowpath a bit (without taking CoffeeScript as normative or overriding or anything like that).

Towards the end of https://mail.mozilla.org/pipermail/es-discuss/2011-November/018332.html I made an argument  that own-ness of properties  is an implementation choice that normally should not be of concern to application clients of an object-based abstraction.   Own-ness  is primarily relevant to abstraction implementors or somebody who is using reflection to examine the implementation structure of an object.

Hopefully reflection is tucked away in a obscure but pleasant corner of the language and not widely used for routine application logic. Generally, reflection doesn't deserve (or require) statement level support.

That raises the question of the role of the for-in statement in the language (besides just being an obsolete and less useful alternative to for-of).  Being a full fledged syntactic statement of the language, it certainly isn't hiding in an obscure corner.  If we want to think of it as something other than an over exposed reflection tool, what is it for?.  The best expression of this that I can come up with, is that for-in is a statement that is primarily useful for iterating the "data member keys" of simple record and array like data abstractions. From that perspective,  own-ness again is something that should primarily be an implementation concern.  Clients who are iterating over my "public" data members shouldn't  be concerned about whether or not I decided to implement my data abstraction using a tree of objects or be impacted if I change my mind.

To me, for-own-in makes it too easy for client code to create dependencies upon what should inconsequential implementation decisions. 

We have a goal of making ES a language that is better for creating and using abstractions.  For-own-in is a tool that tunnels through abstractions.  Such a tool is fine as part of the reflection facility, but making it a full fledged statement seems like it would be creating an attractive nuisance.
> 
> We could make just-so meanings for destructuring in for-in, also inspired by CoffeeScript (and JS1.7, which did this too while muddying the waters by failing to separate iteration protocol into for-of):
> 
>  for ([k, v] in o) ...;

Clearly, this isn't a general destructuring.  It is a special syntactic form that is mimicking array destructuring syntax. We could probably have a long thread about whether such mimicry is clever language design or a confusing creole.  I reserve my opinion on the general questions. 

> 
> Our current position is "use for-of and an items helper function":
> 
>  import items from "@reflect"; // currently @iter; could be part of standard prelude
> 
>  for ([k, v] of items(o)) ...;

see the main part of the message I referenced above. Pure functional filters like item are unfriendly to collection abstracton builders. 

> 
> But I think detailing the design of ES6 must be allowed to entertain an even easier-to-use extension to for-in.

Another simplification would be to make default iterator produce {key,value} item objects,

Then we have three concise formulations:

for ({key, value} of o) ...;
for  ({key} of o) ...;
for ({value} of o) ...
>  
> If you want values not keys, then per the current proposal you use
> 
>  for (v of values(o)) ...;
> 
> given the necessary values import, or inclusion in a standard prelude.
> 
> There's a hole vs. CoffeeScript: we do not want for-of on a plain Object to iterate over enumerable property values. Arrays, yes, Objects, no -- no Object.prototype. at iterator. So no |for (v of o) ...| for o = {p:1, q:2, r:3}.
(I note at this point that there are some huge es-discuss threads on topics such as the above for which the conclusions (if any) have not been extracted. I'm starting to go over them to see what I can extract from them)

I assume that you are arguing that the default @iterator for Object.prototype (however it is provided) does a key enumeration just like ES1-5 for-in.  Or are you arguing that it produces nothing? I'm not exactly sure why either of those is better than |for (v of o) ...| but I think there are a couple threads that I need to digest that drill into the issues.

>  
> Also no for each (v in o) as E4X (ECMA-357) promulgated. SpiderMonkey and Rhino support it and probably will have to carry it, but such "each" does not say its meaning (values not keys) clearly, and it doesn't compose with "own" nicely.
> 
> But with destructuring for-in, you could write
> 
>  for ([, v] in o) ...;

currently the grammar don't support the above hole syntax.  I wouldn't be a support for adding it.
> 
> This is a bit ugly (holes never look pretty, even when they're useful).
> 
> Not sure what I think of this but I thought I'd throw it out here on es-discuss. The reason I bring it up is twofold: 1) for own (k in o) still needs to be discussed; 2) the for ([k, v] of items(o)) ...; tax is a bit higher than I'd like.

and I'm trying to write spec. language for all of this right now, so it is a good time to make some decisions. 

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120201/1dab9427/attachment-0001.html>


More information about the es-discuss mailing list