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
Ok, I see. So it's true that the current Proxy API doesn't support promises
that would throw on instanceof when unresolved and return a boolean when
resolved. The main reason is that we didn't want proxies to meddle with the
inheritance chain, in particular giving proxies the ability to implement
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
On 11/22/10 10:13, Brendan Eich wrote:
{ foo : G : 33 }
0. let typedObj = { foo : 33 } : { foo : G }; // a la ES4
1. let typedObj = { foo :: G : 33 }; // the guards strawman
2. let typedObj = { (foo : G) : 33 }; // the ML-ish way
3. let typedObj = { foo @ G : 33 };
I'd expect that
o = { a : b = 5 }
Was legal now, setting both o.a and b to 5. Not at a shell, is there an
exception in the grammar for assignment expressions in the value position?
{ a = 5 : T } might work, though.
Mike
On Nov 22, 2010 6:09 PM, Waldemar Horwat walde...@google.com wrote:
On
On Nov 22, 2010, at 3:08 PM, Waldemar Horwat wrote:
On 11/22/10 10:13, Brendan Eich wrote:
{ foo : G : 33 }
0. let typedObj = { foo : 33 } : { foo : G }; // a la ES4
1. let typedObj = { foo :: G : 33 }; // the guards strawman
2. let typedObj = { (foo : G) : 33 };
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
On 11/22/10 15:16, Brendan Eich wrote:
{name: type = value} // Adding a type annotation
Isn't the last ambiguous with legal JS today (well, with const, but that's not
important AFAICT):
Yeah, you're right. This won't work.
Waldemar
___
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
I think there is too much fear of changing the semantics of for-in. Its
semantics is already rather fuzzy. Allowing meta-programmability of for-in
(instead of creating a new for-:) syntax doesn't create any additional
surprises or hazards for JS programmers.
1. We have already agreed on an
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
On Nov 22, 2010, at 4:07 PM, Andreas Gal wrote:
Executive summary: iterate() is equivalent to enumerate(), both should work
with for-in. We already agreed to accept enumerate, forcing iterate() into
its own syntax is arbitrary. We can discuss sacrificing future-proofness and
stringify
I somehow suspect stringifying the iterator next() return value from for-in
machinery will not placate folks who want for-in not to be metaprogrammable.
Nor would it work -- you wouldn't be able to get the values() or properties()
iteration behavior, for example. It would be the worst of all
-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
// es3 way
(function()
{
var x = 1;
return function()
{
return ++x;
}
})();
// current es6/SM1.8 way
let(x = 1) function()
{
return ++x;
}
// new more readable sugar
function()
{
static x = 1; // hello c/c++
return ++x;
}
Implementation, when compiling source code, just
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
38 matches
Mail list logo
