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.@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_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
