Rather than adding additional confusion by trying to comment on snippets
from this thread, I think I'll just state my current opinions on the subject
and the principles that they are based upon:
1a) New semantics should use new syntax in a manner that clearly avoids
confusion with existing syntax.
1b) Syntax should generally be suggestive of a reasonable interpretation of
the semantic
1c) Harmony is not being designed using the "no new syntax" rule
1d) There is nothing sacred about "for" as the initial keyword of an
enumeration statement.
From these I conclude that new iteration semantics should be syntactically
distinct from the current for-in and probably the greater the syntactic
distance from for-in the better. Following these principles, here is a
suggestion for a new enumeration statement that makes use of existing
reserved words:
enum key with keys(x) {
alert(key)
}
enum val with values(x) {
alert(val)
}
enum [key, val] with properties(x) {
alert("x." + key + " = " + val);
}
Since this is a new form, it can impose new syntactic conventions. For
example, it always creates new bindings in the block that it iterates. An
explicit var or let keyword is not needed. Also "with" has much broader
semantic implications than "in"
2) Whenever possible, less general pre-existing syntactic forms should be
redefined to desugar into new more general forms.
ES1-5 for-in can be defined via desugaring to enum-with, for example:
//desugar: for (var x in foo) {alert(foo[x])}
var x;
enum __x with __ES5forinEnumerator(x) {
x=__x;
{alert(foo[x])}
}
3) Proxy traps should be defined based upon the new, more general semantics
not legacy less general semantics.
Define the traps necessary to support enum-with and depend upon the
desugaring to take care of legacy for-in.
4) Provide builtin-library alternatives for new statements that can be used
without down-rev syntax errors:
Iterator.prototype.enumWith = function (func) {
enum each with this {
func(each)
}
}
keys(x).enumWith(function(key){alert(key)});
values(x).enumWith(function(val){alert(val)});
properties(x).enumWith(function([key,val]){alert("x." + key + " = " +
val)});
Leave it to library writers as to whether or not down-rev libraries are
actually implemented.
-----Original Message-----
From: Brendan Eich
Sent: Monday, November 22, 2010 12:48 PM
To: Oliver Hunt
Cc: es-discuss
Subject: Re: Nov 18 notes
On Nov 22, 2010, at 12:39 PM, Brendan Eich wrote:
On Nov 22, 2010, at 12:09 PM, Oliver Hunt wrote:
How do library authors help? They can't add value enumeration of
anything as that will break any existing code that uses for(in) over any
of their objects.
As Tom pointed out (re-read his message :-|), they can make enumeration
work for large/lazy/infinite objects. No non-string non-keys required.
The important point here is that for-in won't choke old browsers. New
library code in the near term (when Harmony and pre-Harmony impls are in the
field), assuming we let for-in be metaprogrammed in Harmony, can
object-detect and meta-program for-in, and client *and* library code can use
for-in and it will fail soft or fall back by other means.
Not so if we add new syntax (for-: or anything old browsers will choke on).
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
