Beautiful.
What do question marks in value (as opposed to key) positions mean?
Example: { a: x? }
How does this work grammatically (ternary operator…)?
On Feb 1, 2013, at 5:28 , Andreas Rossberg rossb...@google.com wrote:
I wrote up the semantics of refutable destructuring as discussed in
Le 31/01/2013 22:48, Kevin Gadd a écrit :
I ask this because the lack of weak references (or any suitable
substitute mechanism) comes up regularly when dealing with the
challenge of porting native apps to JavaScript, and it leads people to
consider extremely elaborate workarounds just to build
On Fri, Feb 1, 2013 at 2:06 AM, David Bruant bruan...@gmail.com wrote:
I don't understand the connection between the lack of weak references and
emulating a heap in a typed array.
For an algorithm that needs weak references to be correct, the only
way to implement that algorithm in JavaScript
Le 01/02/2013 12:21, Kevin Gadd a écrit :
On Fri, Feb 1, 2013 at 2:06 AM, David Bruant bruan...@gmail.com wrote:
I don't understand the connection between the lack of weak references and
emulating a heap in a typed array.
For an algorithm that needs weak references to be correct, the only
way
Indeed, and Continuum uses the same strategy for implementing WeakMap
currently. To my knowledge, the circumstances that makes that
implementation of WeakMap fail is unlikely to arise except in the case of a
membrane. As a polyfill provided to developers devloping with ES5 as a
target, this is
And by fail I mean result in a set of objects that next gets collected by
the GC correctly despite being otherwise fit to be collected.
On Fri, Feb 1, 2013 at 10:12 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:
Indeed, and Continuum uses the same strategy for implementing WeakMap
On 1 February 2013 10:56, Axel Rauschmayer a...@rauschma.de wrote:
Beautiful.
What do question marks in value (as opposed to key) positions mean?
Example: { a: x? }
Not much: a plain identifier 'x' is always matches anyway, i.e. is
already irrefutable, so wrapping a '?' around it does not
A postfix '?' would require backtracking when the next '}' is found...I
think?
On Fri, Feb 1, 2013 at 12:21 PM, Andreas Rossberg rossb...@google.comwrote:
On 1 February 2013 10:56, Axel Rauschmayer a...@rauschma.de wrote:
Beautiful.
What do question marks in value (as opposed to key)
On 1 February 2013 18:24, Brandon Benvie bran...@brandonbenvie.com wrote:
A postfix '?' would require backtracking when the next '}' is found...I
think?
Yeah. I admit that I don't remember much of the earlier discussions on
respective parsing difficulties. Naively, it would seem to me that a
On 1 February 2013 20:00, Andreas Rossberg rossb...@google.com wrote:
On 1 February 2013 18:24, Brandon Benvie bran...@brandonbenvie.com wrote:
A postfix '?' would require backtracking when the next '}' is found...I
think?
Yeah. I admit that I don't remember much of the earlier discussions on
Thinking about it further, I'm pretty sure the parsing looks like:
find '?', parse next expression, parse next token. If that token is ':'
then the expression is a ternary, otherwise it's a refutable expression
But if this is limited to LHS assignables then either works since the only
things
Le 1 févr. 2013 à 20:00, Andreas Rossberg rossb...@google.com a écrit :
On 1 February 2013 18:24, Brandon Benvie bran...@brandonbenvie.com wrote:
A postfix '?' would require backtracking when the next '}' is found...I
think?
Yeah. I admit that I don't remember much of the earlier
Brandon Benvie wrote:
A postfix '?' would require backtracking when the next '}' is
found...I think?
First, let me kill the idea of prefix-'?'.
Prefix-'?' in an AssignmentPattern in an AssignmentExpression that is an
ExpressionStatement is ambiguous with the '?' in a
ConditionalExpression,
Brendan Eich wrote:
Prefix-'?' in an AssignmentPattern in an AssignmentExpression that is
an ExpressionStatement is ambiguous with the '?' in a
ConditionalExpression, if the programmer mistakenly relies on ASI as
if prefix-'?' were not used. Consider refactoring ES6 code with
prefix-'?' from
Claude Pache wrote:
In case (1), there is no ambiguity with the conditional operator. In
case (2), one has to further analyse where a Pattern could appear.
Patterns can appear in formal parameter position, on the left of
assignment ('=', not '+=' etc.), on the left of '=' in an initialized
Brendan Eich wrote:
One solution already used in ECMA-262 to regain LR(1) parsing of the
standard grammar is lookahead restriction. Observe that with
postfix-'?' in patterns, the legal lookahead set is {'=', ':' , ',',
'}', ']'}. So we could simply write a lookahead restriction.
Amended per
Friday afternoon dreaming...
Now that we have introduced class declarations, I occasionally discover
situations where I need to create a singleton specialization of some class. One
way to do that is to apply a new operator to an anonymous class expression.
For example,
let p = Proxy(target,
Le 01/02/2013 22:02, Allen Wirfs-Brock a écrit :
Something like this can still be expressed in the current draft of ES6 as:
let p = Proxy(target, {
__proto__: VirtualObject.prototype,
get(key, receiver) {...},
set(key,value, reciever) {...}
});
This is ugly in its use of
How about a new version of Object.create, e.g. Object.make? Roughly:
Object.make = function (proto, props) {
return props ? Object.create(proto,
Object.getOwnPropertyDescriptors(props)) : Object.create(proto);
};
// with Object.getOwnPropertyDescriptors() having the obvious definition
Previously:
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018476.html
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014428.html
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
David Bruant wrote: David Bruant wrote:
Garbage collectors have evolved and cycles aren't an issue any longer, weak
references or not. Kevin Gadd wrote:
Cycles are absolutely an issue, specifically because JS applications
can interact with systems that are not wholly managed by the
21 matches
Mail list logo
