Allen Wirfs-Brock wrote:
Yep -- I'm warming up to LeftHandSideExpression. It allows new and call
forms, member expressions, primary expressions, but not unparenthesized ternary,
binary or unary operators -- and (crucially for the bug) not anything ending in
AssignmentExpression. Allen?
Is await really the right syntax?
Even with a higher precedence, await is a prefix operator and thus does not
chain well. Typical code is
array.asyncMap(f1).asyncFilter(f2).asyncReduce(f3)
await forces you to write something like:
await (await (await
On 11/11/13 1:22 AM, Jonas Sicking wrote:
I think the number is very low. I think I've heard of a total of four
DOM functions which currently treat not passed as different from
explicitly passed undefined. And we're working on changing those so
that the two are treated the same. Unclear if we'll
That is excellent! Has all the upsides of the best of the other proposals
and none of the downsides.
On Sun, Nov 10, 2013 at 11:33 PM, Corey Frang gnar...@gmail.com wrote:
Just to provide another way of working around it:
var empty = {}; // or even a symbol?
function splice(start = empty,
On Nov 11, 2013, at 6:10 AM, Mark S. Miller wrote:
That is excellent! Has all the upsides of the best of the other proposals and
none of the downsides.
On Sun, Nov 10, 2013 at 11:33 PM, Corey Frang gnar...@gmail.com wrote:
Just to provide another way of working around it:
var empty =
On Fri, Nov 8, 2013 at 1:35 PM, Mark S. Miller erig...@google.com wrote:
(re: weakrefs and post-mortem finalization)
They are needed for many other things, such as
distributed acyclic garbage collection (as in adapting the CapTP ideas to
distributed JS).
I'm not convinced acyclic distributed
On Mon, Nov 11, 2013 at 9:21 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Nov 11, 2013, at 6:10 AM, Mark S. Miller wrote:
On Sun, Nov 10, 2013 at 11:33 PM, Corey Frang gnar...@gmail.com wrote:
Just to provide another way of working around it:
var empty = {}; // or even a symbol?
Doh! My mistake. I was momentarily attributing the old semantics to default
parameter assignment, in which case we wouldn't have had the problem in the
first place.
On Mon, Nov 11, 2013 at 9:21 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Nov 11, 2013, at 6:10 AM, Mark S. Miller
On Nov 11, 2013, at 12:51 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Yep -- I'm warming up to LeftHandSideExpression. It allows new and call
forms, member expressions, primary expressions, but not unparenthesized
ternary, binary or unary operators -- and (crucially for the bug)
On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Fri, Nov 8, 2013 at 1:35 PM, Mark S. Miller erig...@google.com wrote:
(re: weakrefs and post-mortem finalization)
They are needed for many other things, such as
distributed acyclic garbage collection (as in
On Nov 10, 2013, at 6:12 PM, Boris Zbarsky wrote:
...
I believe even for all of these, we could treat them as overloads on the
type of some argument, where we allow undefined as a type that matches
the argument not being present or an argument being optional.
So a viable way forward
On 11/11/13 1:37 PM, Allen Wirfs-Brock wrote:
My, perhaps more radical, recommendation would be to only do overloading based
upon argument counts and to treat all type overloads for a given argument
length as union types that are left to a function's implementation to
discriminate.
We could
I hate to bring this up, as I'm sure I've missed a bunch of the arguments
that define WHY, but if this is the case, it seems unintuitive to me that
passing undefined still results in a default param being set.
function test(a = 1) { console.log(a); }
test(); // gets 1 - yay
test(undefined); //
On 11/11/2013 11:31 AM, Corey Frang wrote:
I hate to bring this up, as I'm sure I've missed a bunch of the
arguments that define WHY, but if this is the case, it seems
unintuitive to me that passing undefined still results in a default
param being set.
function test(a = 1) { console.log(a);
Sure, it makes some sense when you see it like that :)
I retract my this doesn't make sense
I guess we are stuck with (...args)
On Mon, Nov 11, 2013 at 2:37 PM, Brandon Benvie bben...@mozilla.com wrote:
On 11/11/2013 11:31 AM, Corey Frang wrote:
I hate to bring this up, as I'm sure I've
I haven't been able to read through all of this very thoroughly but I would
like to inject that I have a use case right now for some sort of callback
on a WeakMap that notifies AFTER the key has been GC'd but before the value
has been released. If this already exists and I just can't locate it I
On 11/11/13 2:43 PM, Matthew Robb wrote:
I haven't been able to read through all of this very thoroughly but I
would like to inject that I have a use case right now for some sort of
callback on a WeakMap that notifies AFTER the key has been GC'd but
before the value has been released.
Alas in addition to assuming that the Arguments object does not have the Array
prototype, ExtJS also relies on the Array prototype not containing a property
named values.
So, it seems that we’ll need to remove .values from the Array prototype.
—Oliver
What I am suggesting would not be bound to a WeakRef rather to the WeakMap.
So in my mind it seems like the WeakMap can maintain a strong ref to the
values it stores (not the keys obviously) and before the value get's
removed from that WeakMap, fire off a notifier.
On Mon, Nov 11, 2013 at 11:46
On 11/11/13 2:47 PM, Oliver Hunt wrote:
Alas in addition to assuming that the Arguments object does not have the Array
prototype, ExtJS also relies on the Array prototype not containing a property
named values.
So, it seems that we’ll need to remove .values from the Array prototype.
Oliver,
On Mon, Nov 11, 2013 at 2:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/11/13 2:47 PM, Oliver Hunt wrote:
Alas in addition to assuming that the Arguments object does not have the
Array prototype, ExtJS also relies on the Array prototype not containing a
property named values.
So, it
On 11/11/13 2:51 PM, Matthew Robb wrote:
What I am suggesting would not be bound to a WeakRef rather to the
WeakMap. So in my mind it seems like the WeakMap can maintain a strong
ref to the values it stores (not the keys obviously)
The whole point of a weakmap is that it does not maintain a
Apparently i missed that thread entirely
Something i pondered before just removing .values () (that SM has already done)
was essentially adding yet another property mode, essentially “ignore in
|with|”. It’s technically fairly heavyweight, but it would resolve the general
problem of libraries
I thought @@unscopeables were (essentially) Symbols, have i been confused? Are
we overloading @@ to mean different things?
—Oliver
On Nov 11, 2013, at 12:01 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Nov 11, 2013 at 2:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On
Right, but the revised spec. for @@unscopables isn't in the Rev21 draft.
See https://bugs.ecmascript.org/show_bug.cgi?id=1908 for the changes that will
be in Rev22.
Allen
On Nov 11, 2013, at 12:01 PM, Rick Waldron wrote:
On Mon, Nov 11, 2013 at 2:59 PM, Boris Zbarsky
@@unscopable is the Symbol that is the property key that is used access the set
of with-adverse properties for an object.
On Nov 11, 2013, at 12:07 PM, Oliver Hunt wrote:
I thought @@unscopeables were (essentially) Symbols, have i been confused?
Are we overloading @@ to mean different
On Mon, Nov 11, 2013 at 3:06 PM, Oliver Hunt oli...@apple.com wrote:
Apparently i missed that thread entirely
Something i pondered before just removing .values () (that SM has already
done) was essentially adding yet another property mode, essentially “ignore
in |with|”.
That's essentially
On Mon, Nov 11, 2013 at 3:13 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Right, but the revised spec. for @@unscopables isn't in the Rev21 draft.
I'm looking at rev21, dated Nov 8.
Rick
See https://bugs.ecmascript.org/show_bug.cgi?id=1908 for the changes that
will be in Rev22.
On Mon, Nov 11, 2013 at 3:13 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Right, but the revised spec. for @@unscopables isn't in the Rev21 draft.
See https://bugs.ecmascript.org/show_bug.cgi?id=1908 for the changes that
will be in Rev22.
Sorry, I misread this, please ignore my
For reference, i’ve just removed the API from JSC. Default iterator still does
the right thing.
—Oliver
On Nov 11, 2013, at 12:51 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Nov 11, 2013 at 3:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Right, but the revised
On Mon, Nov 11, 2013 at 12:12 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff jason.orendo...@gmail.com
JS users do not want RPC systems where one process's memory usage
depends on getting per-object callbacks from an untrusted peer's GC
On Mon, Nov 11, 2013 at 1:09 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Mon, Nov 11, 2013 at 12:12 PM, Mark S. Miller erig...@google.com
wrote:
On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff
jason.orendo...@gmail.com
JS users do not want RPC systems where one process's
Just a user-experience report with traceur: the following code fails to
compile in the repl.html and command line compiler:
-
import {WrapNewObjectTransformer} from './WrapNewObjectTransformer';
export function transcode(src, url) {
var file = new SourceFile(url, src);
var reporter =
(parenthetical aside replying to a parenthetical aside!
Mark S. Miller wrote:
If anything, local manual deallocation should be easier, and these
have already proven hard enough that people (except C++
and Rust
programmers) have turned to local GC.
/be)
Note that in Chrome the devtools are remote and error.stack is a getter
which issues a remote method call to the backend. Only when the stack
property is accessed will the internal representation be converted to a
string. Anything else is too expensive.
A plain JS object format would be much
To improve JSON interoperability the IETF should not define a more
restricted version of JSON than defined by Ecma-404.
Parsers exist that can parse 42 today and parsers that cannot parse
42 today can be meaningfully upgraded to do so too. This would not
break those parsers, unless they depend on
To be clear, this is a Last Call comment on
http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07 The JSON Data
Interchange Format (draft-ietf-json-rfc4627bis-07).
On Tue, Nov 12, 2013 at 3:01 PM, Anne van Kesteren ann...@annevk.nl wrote:
To improve JSON interoperability the IETF should not
37 matches
Mail list logo
