Hello,
I've been thinking about our IEEE-inherited positive and negative zero and the
proposed ES6 Object.is and new collections semantics. I haven't followed any
discussions about this so I'm basing my understanding purely on the Harmony
wiki and toying around with the preliminary support in
Is 'super' currently limited to method bodies, excluding local functions?
super is limited to ClassBody
Yes, the question is about arrow functions in ClassBody.
Given that 'this' is lexical in arrow functions, I expected any enclosing
'super' to be available, as well, but I cannot confirm
Is 'super' currently limited to method bodies, excluding local functions?
Given that 'this' is lexical in arrow functions, I expected any enclosing
'super' to be available, as well, but I cannot confirm this from the spec.
Yes, clearly super should be able to be used in an arrow function that
Le 03/12/2012 00:06, David Bruant a écrit :
The call to action performs
the original operation on target and remembers the result. After the
trap returns, the proxy returns the remembered result of action.
target = {a:1};
var p = new Proxy(target, {
get: function(target, name,
What eternal[1] invariant does this bypass?
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html
On Mon, Dec 3, 2012 at 3:33 AM, David Bruant bruan...@gmail.com wrote:
Le 03/12/2012 00:06, David Bruant a écrit :
The call to action performs
the original operation on target
I've written up the proposal properly as executable code, a la the Map proposal:
/** A non-stupid alternative to Array.prototype.indexOf */
function indexOfIdentical(keys, key) {
for (var i = 0; i keys.length; i++) {
if (keys[i] is key) { return i; }
}
return -1;
}
Correct me if this stuff isn't actually going to end up as ES6, but my
reading of meeting notes from July? indicate this is in:
Instead of
import {Name} from '@name';
const keysName = new Name; // These should be non global.
const valsName = new Name;
class MultiMap { ... }
You can do
On Mon, Dec 3, 2012 at 10:08 AM, Brandon Benvie
bran...@brandonbenvie.com wrote:
Correct me if this stuff isn't actually going to end up as ES6, but my
reading of meeting notes from July? indicate this is in:
Instead of
import {Name} from '@name';
const keysName = new Name; // These
Hello everyone,
Reposting, I think my previous attempt got stuck in a filter or something,
because I somehow managed to have the code there in several copies.
I was thinking about sorting algorithms yesterday and I realized that ES
implementations may have different sorting algorithms in use,
Jussi Kalliokoski wrote:
Hello everyone,
Reposting, I think my previous attempt got stuck in a filter or
something, because I somehow managed to have the code there in several
copies.
You have three messages total on this topic at
On Mon, Dec 3, 2012 at 8:46 PM, Brendan Eich bren...@mozilla.org wrote:
You have three messages total on this topic at
https://mail.mozilla.org/**pipermail/es-discuss/2012-**December/https://mail.mozilla.org/pipermail/es-discuss/2012-December/
Oh, sorry about the noise, I should've checked
It's abort stability, and I think it's better to keep it un-stable for
performance performance.
On Mon, Dec 3, 2012 at 10:46 PM, Brendan Eich bren...@mozilla.org wrote:
Jussi Kalliokoski wrote:
Hello everyone,
Reposting, I think my previous attempt got stuck in a filter or
something,
I was just reading through the binary data proposal [1] and I have a few
comments / questions:
First of all, how will this integrate with the Typed Arrays? Will a struct
have an intrinsic ArrayBuffer? What about an ArrayType instance? If they
do, how will it react to typeless properties? Are
On Mon, Dec 3, 2012 at 11:53 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
I was just reading through the binary data proposal [1] and I have a few
comments / questions:
First of all, how will this integrate with the Typed Arrays?
Typed Arrays are already using similar logic
# November 27 2012 Meeting Notes
John Neumann (JN), Norbert Lindenberg (NL), Allen Wirfs-Brock (AWB),
Waldemar Horwat (WH), Brian Terlson (BT), Luke Hoban (LH), Rick Waldron
(RW), Eric Ferraiuolo (EF), Matt Sweeney (MS), Doug Crockford (DC), Nebojša
Ćirić (NC), Yehuda Katz (YK), Erik Arvidsson
# November 28 2012 Meeting Notes
John Neumann (JN), Norbert Lindenberg (NL), Allen Wirfs-Brock (AWB),
Waldemar Horwat (WH), Brian Terlson (BT), Luke Hoban (LH), Rick Waldron
(RW), Eric Ferraiuolo (EF), Doug Crockford (DC), Yehuda Katz (YK), Erik
Arvidsson (EA), Mark Miller (MM), Dave Herman (DH),
# November 29 2012 Meeting Notes
John Neumann (JN), Allen Wirfs-Brock (AWB), Waldemar Horwat (WH), Brian
Terlson (BT), Luke Hoban (LH), Rick Waldron (RW), Eric Ferraiuolo (EF),
Doug Crockford (DC), Yehuda Katz (YK), Erik Arvidsson (EA), Mark Miller
(MM), Dave Herman (DH), Sam Tobin-Hochstadt
On Mon, Dec 3, 2012 at 11:53 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
I was just reading through the binary data proposal [1] and I have a few
comments / questions:
First of all, how will this integrate with the Typed Arrays? Will a struct
have an intrinsic ArrayBuffer? What
On Mon, Dec 3, 2012 at 4:28 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I wonder what was the use case that convinced TC39 to return `this` with
these methods.
Assuming you read the notes, I proposed the agenda item based on the best
practice of ensuring meaningful returns, and
IMHO, a set(key, value) should return the value as it is when you address a
value
var o = m.get(k) || m.set(k, v); // o === v
// equivalent of
var o = m[k] || (m[k] = v); // o === v
a set with a key that returns `this` is a non case so almost as useless as
the void return is.
Usefulness comes
Le 03/12/2012 16:38, Mark S. Miller a écrit :
What eternal[1] invariant does this bypass?
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html
Apparently none... Yet, additionally to the last case I showed, there is
also:
var p = new Proxy({a:1}, {
isExtensible:
On Mon, Dec 3, 2012 at 5:21 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
IMHO, a set(key, value) should return the value as it is when you address
a value
var o = m.get(k) || m.set(k, v); // o === v
// equivalent of
var o = m[k] || (m[k] = v); // o === v
a set with a key
fair enough ... but here there was a typo, right?
set.add( value ).forEach( item = ...send to some operation );
Thanks
On Mon, Dec 3, 2012 at 2:44 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Dec 3, 2012 at 5:21 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I'm not a person of influence, but as a JS developer, I agree with Andrea on
this. I think Map#set() should return the value. I would expect the same
behavior as obj[key] = value. I find Andrea's use case (m.get(k) || m.set(k,
v)) more compelling than the method chaining possibilities.
Nathan
On Mon, Dec 3, 2012 at 5:49 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
fair enough ... but here there was a typo, right?
set.add( value ).forEach( item = ...send to some operation );
Possibly? s/item/value/ ?
Rick
Thanks
On Mon, Dec 3, 2012 at 2:44 PM, Rick
I meant the forEach on a Set which I've never seen before in specs ... ;-)
On Mon, Dec 3, 2012 at 2:54 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Dec 3, 2012 at 5:49 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
fair enough ... but here there was a typo, right?
for what is worth it, my use case is exactly this:
var value = map.has(key) ? map.get(key) : map.set(key, someValue);
which could be inlined easily and it looks less ugly and/or redundant than:
(map.has(key) ? map.get(key) : map.set(key, someValue).get(key))
but I see Rick use cases too ...
From the meeting notes it appears that support for @names is out, which I
believe is quite unfortunate. I'd like to either propose a way to resolve
the issues that caused them to be dropped, or come to an understanding of
what the reason is that they can't be resurrected.
First, I wanted to touch
On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
The simplification I've thought about is eliminating [[Construct]] as an
internal method/Proxy trap and just making the call @@Create/call
consturctor sequence the evaluation semantics of the new operator. But
I've
On Mon, Dec 3, 2012 at 5:55 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I meant the forEach on a Set which I've never seen before in specs ... ;-)
Set and Map both have a forEach method (since rev10 I believe, 15.16.5.5
and 15.14.5.4 respectively)
Rick
crap ... this stuff is not in V8 thought, not in node --harmony at least
... I need to update my polyfills .. !
On Mon, Dec 3, 2012 at 3:05 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Dec 3, 2012 at 5:55 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I meant the
I haven't looked into sort algorithms in a while - how much slower are the
fastest stable ones than the fastest non-stable ones?
I ran into the stability issue recently when implementing a function to
interpret HTTP Accept-Language headers [1]. The language tags in these headers
can have
On Dec 3, 2012, at 3:03 PM, Jason Orendorff wrote:
On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The simplification I've thought about is eliminating [[Construct]] as an
internal method/Proxy trap and just making the call @@Create/call consturctor
On Dec 3, 2012, at 2:00 AM, Claus Reinke wrote:
Is 'super' currently limited to method bodies, excluding local functions?
Given that 'this' is lexical in arrow functions, I expected any enclosing
'super' to be available, as well, but I cannot confirm this from the spec.
Yes, clearly super
+1 (to all sentiments in the message :)
From: Nathan Wallmailto:nathan.w...@live.com
Sent: 12/3/2012 17:53
To: Andrea Giammarchimailto:andrea.giammar...@gmail.com; Rick
Waldronmailto:waldron.r...@gmail.com
Cc: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that the typical iterator form will
be something like:
let iterable = { *[iterator]() { yield 5; } };
Presented without comment...
From: Brandon
On Dec 3, 2012, at 11:53 AM, Jussi Kalliokoski jussi.kallioko...@gmail.com
wrote:
I was just reading through the binary data proposal [1] and I have a few
comments / questions:
First of all, how will this integrate with the Typed Arrays?
Typed Arrays will become a special case of binary
I think the important thing to recognize is that @names was an *extremely* late
proposal, and it's just way too late for ES6, but that doesn't at all mean it's
out for good. The deadline for new features was in the spring of *2011* after
all! Now, the fact that we considered it at all was due
Until ES7. If we try to solve all problems in ES6, it might not ship
earlier than ES7 anyway.
On Mon, Dec 3, 2012 at 4:38 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that
On Dec 3, 2012, at 4:38 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that the typical iterator form
will be something like:
let iterable = { *[iterator]() { yield
let iterable = { *[iterator]() { yield 5; } };
Presented without comment...
I'm sorry, but I reject this kind of argument. That code is simply more
concise than:
let iterable = { [iterator]: function*() { yield 5 } };
Given that the concise notation means that ': function' is
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't buy
the ES7-is-around-the-corner wager for two reasons.
The first reason is that I believe it's likely going to be a lot harder to
get syntax changes into
On Mon, Dec 3, 2012 at 6:14 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't buy
the ES7-is-around-the-corner wager for two reasons.
The first reason
On Dec 3, 2012, at 6:27 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 3, 2012 at 6:14 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't buy
Axel Rauschmayer wrote:
let iterable = { *[iterator]() { yield 5; } };
Presented without comment...
I'm sorry, but I reject this kind of argument. That code is simply
more concise than:
let iterable = { [iterator]: function*() { yield 5 } };
Given that the concise notation means that
Sorry, didn't realize that had another meaning. I mean anything that causes
a syntax error when attempting to run it.
On Mon, Dec 3, 2012 at 9:28 PM, David Herman dher...@mozilla.com wrote:
On Dec 3, 2012, at 6:27 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 3, 2012 at 6:14 PM,
Ah. Gotcha. Yes, that's a good point. But even though such changes are
costly and less needed by ES7, I expect ES7 will nevertheless have
some further syntax enhancements that don't work on ES6. The main
example is the minimality of min-max classes, These really really need
to be made more usable
On Dec 3, 2012, at 6:14 PM, Brandon Benvie bran...@brandonbenvie.com wrote:
I understand that there's limitations on what can be packed into this release
and in particular this proposal pushes the limits.
Look, that's all it comes down to. All the various @names proposals have
problems. No
Brandon Benvie wrote:
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't
buy the ES7-is-around-the-corner wager for two reasons.
Neither ES6 (+1 years) nor ES7 (+4) is around the corner.
You are
On Dec 3, 2012, at 6:35 PM, Brendan Eich bren...@mozilla.org wrote:
Recall the main objection was not the generativity of @names mixed with the
obj.@foo pun (after-dot). It was the usability tax of having to declare
private @foo;
before defining/assiging
obj.@foo = foo;
(in a
David Herman wrote:
(That said, the generativity does worry me. It's a smell.)
Just to be super-sure we grok one another, it's not the generativity by
itself (since nested function declarations are the same, as I mentioned
in the meeting). It is the generativity combined with the obj.@foo
yes, exactly. symbols themselves are, by design, *gen*sym. :)
Dave
- Original Message -
From: Brendan Eich bren...@mozilla.org
To: David Herman dher...@mozilla.com
Cc: Brandon Benvie bran...@brandonbenvie.com, es-discuss discussion
es-discuss@mozilla.org
Sent: Mon, 03 Dec 2012 19:47:24
Hello all,
Because of 8.3.19.1 step 17, [[Call]] returns result completion even if
result.type isn't return.
As the result, [[Call]] may return NormalCompletion(empty), is it expected
behavior?
I think we should change empty to undefined.
For example,
function test() {
var i;
}
var value =
53 matches
Mail list logo
