http://brendaneich.com/2010/11/paren-free/
Fasten your seatbelts, it's going to be a bumpy night!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I'd like to contribute what I think are three not-yet-voiced arguments to
this discussion:
1) Iterators != Collections
First, let me briefly restate what I preceive to be the main point of
contention: if we overload for-in, then client code that previously executed
for (x in obj) with obj being a
On Nov 22, 2010, at 11:35 PM, Brendan Eich wrote:
On Nov 22, 2010, at 11:19 PM, Maciej Stachowiak wrote:
Probably we need to take our time and not rush into a meta-programming-here
syntax variant of for-in. I'll not propose anything better right now.
If the colon is less
On 2010-11-22, at 02:37, David Herman wrote:
if we allowed for-in to be overloaded, I would tell people that they should
deprecate the legacy for-in and replace it with an explicit iterator such as:
for (x in keys(obj))
I have learned a mnemonic for for-in: that it is iterating using
On Nov 23, 2010, at 12:11 AM, Maciej Stachowiak wrote:
One possibility is to add a space as apparently a few other languages do:
for each (var i in x)
Should be unambiguously parsable and easy to understand.
This is what ECMA-357, E4X, does, and it indeed iterates values not keys. The
On Nov 23, 2010, at 5:19 AM, P T Withington wrote:
On 2010-11-22, at 02:37, David Herman wrote:
if we allowed for-in to be overloaded, I would tell people that they should
deprecate the legacy for-in and replace it with an explicit iterator such as:
for (x in keys(obj))
I have
On Nov 23, 2010, at 11:12 AM, Brendan Eich wrote:
Given this, it is useful to identify candidate syntax that doesn't have
perceived showstopper problems, so that we can evaluate the tradeoffs among
the three prongs of the trilemma.
It's a problem if showstopper criteria are not shared in
On 2010-11-23, at 14:14, Brendan Eich wrote:
On Nov 23, 2010, at 5:19 AM, P T Withington wrote:
On 2010-11-22, at 02:37, David Herman wrote:
if we allowed for-in to be overloaded, I would tell people that they should
deprecate the legacy for-in and replace it with an explicit iterator
On 11/23/10 11:12, Brendan Eich wrote:
for (k in keys(o)) ...
for (v in values(o)) ...
for ([k, v] in properties(o)) ...
What are keys, values, and properties here? Global functions? How would
a new object abstraction T customize them just for instances of T?
Waldemar
for (k in keys(o)) ...
for (v in values(o)) ...
for ([k, v] in properties(o)) ...
What are keys, values, and properties here? Global functions?
Those are API's suggested in the strawman:iterators proposal. They would be
importable from a standard module.
How would a new object
On Nov 23, 2010, at 12:14 PM, P T Withington wrote:
Harmony Proxies allow meta-programming of |in| already, via the |has| trap.
So the answer to your quesiton does the `in` operator also get overloaded?
is Yes, but you have to write two traps, iterate and has.
How does the `in` in for-in
How would a new object abstraction T customize them just for instances of T?
By writing its own custom iteration protocol via proxies with the iterate()
trap implemented appropriately. E.g.:
function MyCollection() { }
MyCollection.prototype = {
iterator: function() {
On Nov 23, 2010, at 1:05 PM, Brendan Eich wrote:
If you're implementing a container, then questions of mutability arise.
Immutable container proxies could have iterate, has, and get. Mutable
containers might rather vend iterators via specific API methods, where the
iterators are separate
On 11/23/10 13:05, David Herman wrote:
How would a new object abstraction T customize them just for instances of T?
By writing its own custom iteration protocol via proxies with the iterate()
trap implemented appropriately. E.g.:
function MyCollection() { }
MyCollection.prototype = {
On Nov 22, 2010, at 12:37 AM, Peter van der Zee wrote:
On Mon, Nov 22, 2010 at 6:54 AM, Brendan Eich bren...@mozilla.com wrote:
The ML-ish solution, which is forward compatible, is to parenthesize:
let typedObj = { (prop1:type1): value1, (prop2:type2): value2, ... };
The parentheses
On Mon, Nov 22, 2010 at 8:37 AM, David Herman dher...@mozilla.com wrote:
for (var i : x) ... // must be new iteration
for (var i : T : x) ... // iteration again, but parsed how?
for (var i : T in x) ... // for-in with annotated var
Bummer!
I'm beginning to feel more strongly again
On Nov 22, 2010, at 12:49 AM, Peter van der Zee wrote:
On Mon, Nov 22, 2010 at 8:37 AM, David Herman dher...@mozilla.com wrote:
for (var i : x) ... // must be new iteration
for (var i : T : x) ... // iteration again, but parsed how?
for (var i : T in x) ... // for-in with annotated
On Mon, Nov 22, 2010 at 9:43 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 22, 2010, at 12:37 AM, Peter van der Zee wrote:
On Mon, Nov 22, 2010 at 6:54 AM, Brendan Eich bren...@mozilla.com wrote:
The ML-ish solution, which is forward compatible, is to parenthesize:
let typedObj = {
On Nov 22, 2010, at 1:03 AM, Peter van der Zee wrote:
On Mon, Nov 22, 2010 at 9:43 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 22, 2010, at 12:37 AM, Peter van der Zee wrote:
On Mon, Nov 22, 2010 at 6:54 AM, Brendan Eich bren...@mozilla.com wrote:
The ML-ish solution, which is
My arguments in favor of keeping the existing for-in syntax and making it
meta-programmable:
- Simplicity. Don't underestimate the complexity creep of introducing a new
looping construct. Many small changes add up quickly. Especially for
novices, having two looping constructs that are so similar
On Mon, Nov 22, 2010 at 12:37 AM, Peter van der Zee e...@qfox.nl wrote:
Can't the guards proposal be applied to function parameters as well? Or am
I stepping on land mines there? :)
Yes. Please look at the guards strawman. It's in there.
--
Cheers,
--MarkM
On Nov 22, 2010, at 5:42 AM, Mark S. Miller wrote:
On Mon, Nov 22, 2010 at 1:09 AM, Brendan Eich bren...@mozilla.com wrote:
[...] Before reaching in a reactive way for @, let's slow down and consider
what got us here: over-eager bikeshedding of : instead of in [...]
That's not what got me
On 2010-11-22, at 13:13, Brendan Eich wrote:
That, plus the relative rarity of annotated initialisers (in my best guess --
we can argue about this or try to estimate by adding guards to existing
code), make me still favor (2).
The idea of guards as adjectives (ala C) is a non-starter?
On Nov 22, 2010, at 10:58 AM, P T Withington wrote:
On 2010-11-22, at 13:13, Brendan Eich wrote:
That, plus the relative rarity of annotated initialisers (in my best guess
-- we can argue about this or try to estimate by adding guards to existing
code), make me still favor (2).
The
On Nov 22, 2010, at 2:08 AM, Tom Van Cutsem wrote:
My arguments in favor of keeping the existing for-in syntax and making it
meta-programmable:
- Simplicity. Don't underestimate the complexity creep of introducing a new
looping construct. Many small changes add up quickly. Especially for
On Nov 22, 2010, at 11:12 AM, Brendan Eich wrote:
Would keyword arguments ever be added to JS? Any chance that would
influence the choices made here?
Imponderable unless we reserve : in call expressions such as
foo(arg1: val1, arg3: val3);
to mean named formal parameter association
On Nov 22, 2010, at 11:14 AM, Oliver Hunt wrote:
On Nov 22, 2010, at 2:08 AM, Tom Van Cutsem wrote:
My arguments in favor of keeping the existing for-in syntax and making it
meta-programmable:
- Simplicity. Don't underestimate the complexity creep of introducing a new
looping
On 2010-11-22, at 14:33, Brendan Eich wrote:
Is losing the braces really worth the added complexity?
Perhaps not. Braces are surely as good a way to denote keyword args as any
other flag. It occurred to me that there is no equivalent of object literals
in the languages I know that have
On Nov 22, 2010, at 11:49 AM, Brendan Eich wrote:
On Nov 22, 2010, at 11:14 AM, Oliver Hunt wrote:
On Nov 22, 2010, at 2:08 AM, Tom Van Cutsem wrote:
My arguments in favor of keeping the existing for-in syntax and making it
meta-programmable:
- Simplicity. Don't underestimate the
On Nov 22, 2010, at 12:09 PM, Oliver Hunt wrote:
On Nov 22, 2010, at 11:49 AM, Brendan Eich wrote:
On Nov 22, 2010, at 11:14 AM, Oliver Hunt wrote:
On Nov 22, 2010, at 2:08 AM, Tom Van Cutsem wrote:
My arguments in favor of keeping the existing for-in syntax and making
it
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
On Nov 22, 2010, at 11:49 AM, Brendan Eich wrote:
On Nov 22, 2010, at 11:14 AM, Oliver Hunt wrote:
And all existing standards compliant code can no longer rely on for in doing
what it has done for years. Suddently for in _behaviour_ may change based
on the prototype chain.
That's true
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
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
2a) If existing syntax is given new semantics, it should extend the existing
semantics conservatively. Otherwise, the new semantics should get new syntax.
Perhaps I should have numbered that 1a'). :)
Dave
___
es-discuss mailing list
On Nov 22, 2010, at 3:17 PM, Allen Wirfs-Brock wrote:
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
-Original Message-
From: David Herman
Sent: Monday, November 22, 2010 3:55 PM
To: Allen Wirfs-Brock
Cc: Brendan Eich ; Oliver Hunt ; es-discuss
Subject: Re: Nov 18 notes
1a) New semantics should use new syntax in a manner that clearly avoids
confusion with existing syntax.
1b) Syntax
-Original Message-
From: Brendan Eich
Sent: Monday, November 22, 2010 4:10 PM
To: Allen Wirfs-Brock
Cc: Oliver Hunt ; es-discuss
Subject: Re: Nov 18 notes
On Nov 22, 2010, at 3:17 PM, Allen Wirfs-Brock wrote:
...
enum key with keys(x) {
This is a clever homage to with :-P.
AWB
On Nov 22, 2010, at 5:39 PM, Allen Wirfs-Brock wrote:
AWB: Thanks, I like that. Trying to articulate some principles was the main
point. I felt the thread was feeling like it getting hung up on unstated
and/or unshared prinicples.
I agree, and I try to make mine clear (let me know where
The most frequent (in my hearing) unsatisfied expectation of users of for-in
is not that it is a second form after the C-based for(;;) -- there's no
mention of for(;;). Rather, it is that for (v in [1,2,3]) fails to iterate
1,2,3, instead enumerating 0,1,2.
We can't satisfy this
On Nov 22, 2010, at 7:07 PM, Oliver Hunt wrote:
The most frequent (in my hearing) unsatisfied expectation of users of for-in
is not that it is a second form after the C-based for(;;) -- there's no
mention of for(;;). Rather, it is that for (v in [1,2,3]) fails to iterate
1,2,3, instead
On Nov 21, 2010, at 7:05 PM, Brendan Eich wrote:
On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
Consensus that we should have iterators.
For this, after all these years (JS1.7 added meta-programmable for-in in
2006), I'm grateful, although I wanted to add something your notes did
On Nov 22, 2010, at 11:19 PM, Maciej Stachowiak wrote:
Probably we need to take our time and not rush into a meta-programming-here
syntax variant of for-in. I'll not propose anything better right now.
If the colon is less future-compatible than we like, why not:
foreach (var i in x)
All
On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
Consensus that we should have iterators.
For this, after all these years (JS1.7 added meta-programmable for-in in 2006),
I'm grateful, although I wanted to add something your notes did not report:
To get consensus, we made a tentative
...@mozilla.org]
On Behalf Of Brendan Eich
Sent: Sunday, November 21, 2010 7:05 PM
To: Waldemar Horwat
Cc: Mark S. Miller; es-discuss
Subject: Re: Nov 18 notes
On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
Consensus that we should have iterators.
For this, after all these years (JS1.7 added
On Sun, Nov 21, 2010 at 7:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
[...]
Worse, the use of colon in this new for syntax is confusingly similar to
long-standing future-proofing intentions around runtime type annotations
(aka guards or
On Nov 21, 2010, at 7:21 PM, Chris Sells wrote:
I'm a huge fan of iterators. As far as index goes, I'm not a fan of the use
of the colon. We should take our time, but something that I wanted to throw
into the pot would be to build on the key-based nature of for-in with syntax
like this:
On Nov 21, 2010, at 7:41 PM, Brendan Eich wrote:
On Nov 21, 2010, at 7:21 PM, Chris Sells wrote:
I'm a huge fan of iterators. As far as index goes, I'm not a fan of the use
of the colon. We should take our time, but something that I wanted to throw
into the pot would be to build on the
On Nov 21, 2010, at 7:40 PM, Mark S. Miller wrote:
On Sun, Nov 21, 2010 at 7:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
[...]
Worse, the use of colon in this new for syntax is confusingly similar to
long-standing future-proofing
On Sun, Nov 21, 2010 at 7:48 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 21, 2010, at 7:40 PM, Mark S. Miller wrote:
On Sun, Nov 21, 2010 at 7:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
[...]
Worse, the use of colon in this new
And (sorry, I'll try to keep replies in one message next time) for vs.
forvals does not exactly scream keys vs. values, since for is only
about keys if you know ECMA-262 and expect the mystery meat of enumeration.
IMO, forvals is a non-starter, as is foreach or for each. The for part
of the
On Sun, Nov 21, 2010 at 7:48 PM, Brendan Eich bren...@mozilla.com wrote:
:: is strictly less pleasant, and really kind of taken due to the
precedents I cited. The less pleasant point is the big one IMHO.
Since this is a purely bikeshedding issue, I don't need to be too
embarrassed by posting
On Sun, Nov 21, 2010 at 7:58 PM, Mark S. Miller erig...@google.com wrote:
On Sun, Nov 21, 2010 at 7:48 PM, Brendan Eich bren...@mozilla.com wrote:
:: is strictly less pleasant, and really kind of taken due to the
precedents I cited. The less pleasant point is the big one IMHO.
Since this
Third day rough meeting notes.
Waldemar
instanceof trap for proxies: Withdrawn. Agreed to drop it for now.
Proxy default forwarding handler. Agreed that there should be an easy
way to delegate to a default forwarding handler.
Waldemar: Why not use prototypes to do this?
MarkM, others:
54 matches
Mail list logo
