aside note
let x = q ? 10 : 20;
Why we're reinventing the wheel here is up to me.
/aside
-Message d'origine-
From: Dmitry Soshnikov
Sent: Friday, November 11, 2011 8:54 AM
To: David Herman
Cc: es-discuss Steen
Subject: Re: (Almost) everything is expression
On 11.11.2011
On 11.11.2011 13:26, François REMY wrote:
aside note
let x = q ? 10 : 20;
Why we're reinventing the wheel here is up to me.
/aside
I noted it in the initial letter. Yes, we have the sugar for this
particular case for years (the ternary operator). But also with this I
mention that
Hi,
It reminds me of something I was thinking about recently.
A very common pattern in JS is:
(function(global){
var private1 = 'a';
// ...
global.something = 11;
})(this)
block-scoped variables allow a light-weigth version of this pattern:
-
{
let private1 = 'a';
//
I didn't read your first mail, I've to acknowledge. That doesn't change the
fact the sample was reinventing the wheel.
BTW,your samples all suffer from a big ambuiguity that I think is
unresolvable.
let a = if (foo) {
print('a is foo');
foo;
} else {
// do some longer
which I thought could be turned into:
-
var C = {
let something;
// |this| is the global object
// ...
}
-
But it does not have a return value and as noted in your second message,
there seems to be an ambiguity with object initializers (not only visual but
On 11.11.2011 14:37, David Bruant wrote:
Hi,
It reminds me of something I was thinking about recently.
A very common pattern in JS is:
(function(global){
var private1 = 'a';
// ...
global.something = 11;
})(this)
block-scoped variables allow a light-weigth version of this
On 11.11.2011 14:44, François REMY wrote:
I didn't read your first mail, I've to acknowledge. That doesn't
change the fact the sample was reinventing the wheel.
I still don't see how your this sentence helps taking into account that
I myself noted this case, sorry.
BTW,your samples all
On 11.11.2011 14:52, Axel Rauschmayer wrote:
which I thought could be turned into:
-
var C = {
let something;
// |this| is the global object
// ...
}
-
But it does not have a return value and as noted in your second message, there
seems to be an ambiguity with object
IIRC: Block lambdas.
var C = {|| // note the double pipe
let something;
// |this| is the global object
// ...
return something;
}
This contradicts TCP though. E.g. Ruby supports it and there we can't
`return` from blocks, since block wrapping should not be treated
I think you strongly underestimate the distinction problem. It's *not*
possible to make any difference between the foo statement and the print
statement of your sample, from the compiler point of view. Why would the
foo statement be the one chosen as a return value for the if block? It's
11/11/2011 08:07, Dmitry Soshnikov :
Hi,
(unfortunately Twitter is again doesn't fit for a more than 140 ch
discussion, so moving here)
I'd like to still notice the possibility of accepting the almost
everything is expression approach for JS. After Erlang I very often miss
this
On 11.11.2011 15:48, François REMY wrote:
I think you strongly underestimate the distinction problem. It's
*not* possible to make any difference between the foo statement and
the print statement of your sample, from the compiler point of view.
Why would the foo statement be the one chosen as a
On 11 November 2011 12:48, François REMY fremycompany_...@yahoo.fr wrote:
I think you strongly underestimate the distinction problem. It's *not*
possible to make any difference between the foo statement and the print
statement of your sample, from the compiler point of view. Why would the
foo
On 11.11.2011 16:03, gaz Heyes wrote:
11/11/2011 08:07, Dmitry Soshnikov :
Hi,
(unfortunately Twitter is again doesn't fit for a more than
140 ch discussion, so moving here)
I'd like to still notice the possibility of accepting the
almost everything is
To keep this thread from getting off-track: I am talking about
patterns as a common ground between ES.next spec writers
and JS.current coders. Focusing on patterns now would help
to get JS coders involved in checking current proposals for
consistency/edge cases, instead of leaving that burden
2011/11/11 David Herman dher...@mozilla.com:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the
grammar (though, have to check more precisely), but it can be acceptable
price.
It's a serious price, though. Today if I write:
if (q) { ... }
else { ... }
(f())
In es-next we should be able to subclass an array
function createArraySubclass(proto, ...values) {
return proto | [...values];
}
However when we call `instanceOfSubArray.filter(...)` this method returns a
new Array rather then a new SubArray.
It would seem frustrating to have to overwrite
On Nov 11, 2011, at 3:48 AM, François REMY wrote:
I think you strongly underestimate the distinction problem. ... It's
completelty unclear to me. If there's no way to tell what the return
statement of the block is, there's no way to implement your proposal.
It's actually quite easy to
Insist on enclosing parens, since
( introductory-token
is not otherwise legal
let a = (switch (foo) {
case 10: 100;
default: 200;
});
2. If-expression:
let a = (if (foo) {
print('a is foo');
foo;
} else {
// do some longer stuff
});
3. Try-expressions:
let a = (try {
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
Insist on enclosing parens, since
( introductory-token
is not otherwise legal
let a = ({
print('doing stuff');
100;
});
Even the last is now easily unambiguous.
And is this not clearer than
let a = {||
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
How do you know the difference between a blank block statement and a object
literal? Surely it becomes an expression once an assignment occurs anyway.
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
How do you know the difference between a blank block statement and a
object literal? Surely it becomes
My intent is to use a private name property to allow an object to provide a
constructor for new arrays derived from it. something along the lines of:
function createArraySubclass(proto,...values) {
return proto | [...values].{
[Array.derivedArrayKey](){return proto| [ ]}
}
}
The
On Nov 10, 2011, at 11:07 PM, Dmitry Soshnikov wrote:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the
grammar (though, have to check more precisely), but it can be acceptable
price.
No, it is a runtime incompatibility that shifts meaning, without errors.
switch (x)
thanks, a good suggestion.
Actually they are quite different. The dict proposal is simply defining one
new data types that can be used as a key value store which is guaranteed not to
have any pre-existing key conflicts prior to initial use.
My proposal, defines a general extensible
On Nov 11, 2011, at 2:52 AM, Axel Rauschmayer wrote:
which I thought could be turned into:
-
var C = {
let something;
// |this| is the global object
// ...
}
-
But it does not have a return value and as noted in your second message,
there seems to be an ambiguity with
That the [] decoupling is needed can by seen by the fact that dicts can’t have
a size() method (as opposed to the dictionary solution in the strawman).
On Nov 11, 2011, at 17:45 , Allen Wirfs-Brock wrote:
thanks, a good suggestion.
Actually they are quite different. The dict proposal is
On Nov 11, 2011, at 8:19 AM, Mark S. Miller wrote:
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
How do you know the difference between a blank block
On Nov 11, 2011, at 7:39 AM, Neil Eades wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
Insist on enclosing parens, since
( introductory-token
is not otherwise legal
let a = ({
print('doing stuff');
100;
});
Even the last is now easily unambiguous.
function createArraySubclass(proto,...values) {
return proto | [...values].{
[Array.derivedArrayKey](){return proto| [ ]}
}
}
I’m curious: Why wouldn’t one extend Array, instead?
function SubArray() {
}
SubArray.prototype = Object.create(Array.prototype);
On Fri, Nov 11, 2011 at 9:13 AM, David Herman dher...@mozilla.com wrote:
[...]
Hence my do-expressions:
http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions
or Brendan's subtly-disambiguated-block-statement-expressions:
On Nov 11, 2011, at 9:13 AM, David Herman wrote:
On Nov 11, 2011, at 8:19 AM, Mark S. Miller wrote:
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
On 11.11.2011 20:36, Brendan Eich wrote:
On Nov 10, 2011, at 11:07 PM, Dmitry Soshnikov wrote:
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the grammar
(though, have to check more precisely), but it can be acceptable price.
No, it is a runtime incompatibility that
I implemented this for Traceur last week. The abstraction is leaky
since Traceur does not have private names yet but it is still good
enough for a demo.
http://traceur-compiler.googlecode.com/svn/trunk/example/collection.html
Instead of private names we just use Object.define*
On Fri, Nov 11,
On Nov 11, 2011, at 9:50 AM, Allen Wirfs-Brock wrote:
do-expression is a very good solution
Why thank you! ;-)
How gorgeous is that?
not very...
but if I see any of:
let a = do {...
let a = {|| ...
let a = { ...
I immediately know what follows. That is gorgeous...
I'm not
On 11 November 2011 17:13, David Herman dher...@mozilla.com wrote:
Your idea of mandatory parens is still valid (if, IMO, a bit
unsatisfyingly verbose) for most statement forms. It's only the
block-statement-expression that doesn't work. Hence my do-expressions
It should also apply to
On 11 November 2011 18:01, Dmitry Soshnikov dmitry.soshni...@gmail.comwrote:
var foo = {
// do stuff
100;
};
What would be the result of a labelled statement? You'd need labels to work
within expressions since you'd probably want to do:
x=loop:for(i=0;i10;i++){
}
but then what if you do:
On 11.11.2011 21:13, David Herman wrote:
On Nov 11, 2011, at 8:19 AM, Mark S. Miller wrote:
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com
mailto:gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
On Nov 11, 2011, at 9:47 AM, Axel Rauschmayer wrote:
function createArraySubclass(proto,...values) {
return proto | [...values].{
[Array.derivedArrayKey](){return proto| [ ]}
}
}
I’m curious: Why wouldn’t one extend Array, instead?
the problem is with built-ins like
On 11.11.2011 22:25, gaz Heyes wrote:
On 11 November 2011 18:01, Dmitry Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
var foo = {
// do stuff
100;
};
What would be the result of a labelled statement? You'd need labels to
work within
+1 !!
On Nov 11, 2011, at 10:02 AM, Erik Arvidsson wrote:
I implemented this for Traceur last week. The abstraction is leaky
since Traceur does not have private names yet but it is still good
enough for a demo.
http://traceur-compiler.googlecode.com/svn/trunk/example/collection.html
On 11 November 2011 18:29, Dmitry Soshnikov dmitry.soshni...@gmail.comwrote:
This is why the topic is called *(Almost)* everything In general
case we may not include this case with label-statement into proposal, since
the construction you wrote isn't practice IMO. But, we should consider
We've all looked at jQuery code and envied the conciseness of its chaining
APIs. Most of us also looked at it and thought; Yuk, making everything a
method of jQuery and always return the jQuery object is ugly.
However, I (with some help) realized that the .{ operator can be used to
solve most of
Got it, related to what you solve in generic classes with This-types
(covariance vs. contravariance...).
// assume |this| is the source collection
if (this[Array.derivedArrayKey]) A = this[Array.derivedArrayKey](); else A
= [ ];
Another possibility:
if
On 11.11.2011 22:48, gaz Heyes wrote:
On 11 November 2011 18:29, Dmitry Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
This is why the topic is called *(Almost)* everything In
general case we may not include this case with label-statement
into
On Nov 11, 2011, at 10:52 AM, Axel Rauschmayer wrote:
Got it, related to what you solve in generic classes with This-types
(covariance vs. contravariance...).
// assume |this| is the source collection
if (this[Array.derivedArrayKey]) A = this[Array.derivedArrayKey](); else A
= [
Having recently bitten by a mistyped property name (see code underneath
signature), I think I might prevent the extension of instances more often. But
what is the best way of doing so?
Variant 1: prevents subtyping the constructor
function Point(x, y) {
this.x = x;
this.y =
Object.getPrototypeOf(this) === Point.prototype = this instanceof Point
And I don't understand your problem _
On Fri, Nov 11, 2011 at 8:11 PM, Axel Rauschmayer a...@rauschma.de wrote:
Having recently bitten by a mistyped property name (see code underneath
signature), I think I might prevent
document.querySelector('#my-element').{
style.{
'color': 'red',
'padding': '5px'
}.
textContent: 'Hello'
};
I don't think I've seen this form of the .{ syntax discussed before. Is an
expression being used as the LHS of an object literal property assignment?
What does foo.{
Hi,
I think adding Object.getOwnPropertyDescriptors would be great.
It could be implemented like this:
Object.getOwnPropertyDescriptors = function ( object ) {
var propertiesDescriptor = { };
Object.getOwnPropertyNames( object ).forEach( function ( key ) {
propertiesDescriptor[
It appears to be assigning multiple properties in place and at once and
returning the original object if I am understanding correctly.
On Fri, Nov 11, 2011 at 1:27 PM, Luke Hoban lu...@microsoft.com wrote:
document.querySelector('#my-element').{
style.{
'color': 'red',
'padding':
I'm sorry, i don't understand the semantics you're going for here. What is
document.querySelector('#myTable').{
querySelectorAll('.firstColumn').{
style.{background: 'red', border: '2px solid black'},
textContent: 'first column'
},
querySelectorAll('.lastColumn').{
On Fri, Nov 11, 2011 at 11:27, Luke Hoban lu...@microsoft.com wrote:
document.querySelector('#my-element').{
style.{
'color': 'red',
'padding': '5px'
}.
textContent: 'Hello'
};
I don't think I've seen this form of the .{ syntax discussed before. Is an
expression
How gorgeous is that?
It's normal and consistent with other blocks, I'd say.
Sorry, that was an (American?) English colloquialism -- a rhetorical question
meaning that's gorgeous!
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
It has already been proposed, look here:
http://wiki.ecmascript.org/doku.php?id=strawman:extended_object_api
On Nov 11, 2011, at 20:30 , Xavier MONTILLET wrote:
Hi,
I think adding Object.getOwnPropertyDescriptors would be great.
It could be implemented like this:
On Nov 11, 2011, at 10:50 AM, Erik Arvidsson wrote:
We've all looked at jQuery code and envied the conciseness of its chaining
APIs. Most of us also looked at it and thought; Yuk, making everything a
method of jQuery and always return the jQuery object is ugly.
Beauty is in the eye of the
On Fri, Nov 11, 2011 at 11:38, Oliver Hunt oli...@apple.com wrote:
But ignoring that, the decision we made at last november's meeting was that
DOM attributes would be specified as setters on the prototype, so
someElement.style.{background:blue, border: 2px solid black}
would add to own
On 11.11.2011 23:44, David Herman wrote:
How gorgeous is that?
It's normal and consistent with other blocks, I'd say.
Sorry, that was an (American?) English colloquialism -- a rhetorical question meaning
that's gorgeous!
offtopic
And what does it mean? :) I translated it as how do you like
On Fri, Nov 11, 2011 at 4:23 PM, Xavier MONTILLET xavierm02@gmail.com
wrote:
Object.getPrototypeOf(this) === Point.prototype = this instanceof Point
Actually, no. this instanceof Point = Object.getPrototypeOf(this) ===
Point.prototype, but not the other way around.
And I don't
And why can't you call the superconstructor at the end?
It'd work the exact same except it could overwrite some of the
properties you wrote... but since those things would more likely be in
prototype, it's not much of an issue.
On Fri, Nov 11, 2011 at 10:05 PM, Juan Ignacio Dopazo
And why can't you call the superconstructor at the end?
It'd work the exact same except it could overwrite some of the
properties you wrote... but since those things would more likely be in
prototype, it's not much of an issue.
That is definitely a possibility! It does have one drawback,
I would translate How X is that? as that is very X! :)
Dave
On Nov 11, 2011, at 12:26 PM, Dmitry Soshnikov wrote:
On 11.11.2011 23:44, David Herman wrote:
How gorgeous is that?
It's normal and consistent with other blocks, I'd say.
Sorry, that was an (American?) English colloquialism -- a
2011/11/11 David Herman dher...@mozilla.com:
On Nov 11, 2011, at 3:48 AM, François REMY wrote:
I think you strongly underestimate the distinction problem. ... It's
completelty unclear to me. If there's no way to tell what the return
statement of the block is, there's no way to implement
Late to the party, but I've brought more booze.
On Nov 5, 2011, at 2:41 PM, Brendan Eich wrote:
We have:
1. Should an array pattern always query 'length'?
2. If the answer to (1) is no, then should ... in an array pattern query
'length'?
On reflection and at this point in the thread,
On Nov 11, 2011, at 2:51 PM, Mike Samuel wrote:
If statements as expressions goes forward, we should look into
tweaking completion values.
IMHO, a code maintainer who sees
resource = ..., foo(resource)
would expect to be able to wrap the use of resource in a try finally thus
I really need to know why WeakMaps don't accept primitives as keys, can anyone
please reply ?
Thanks!
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
On Thursday, 2011-11-10 at 10:31 , Irakli Gozalishvili
On Nov 11, 2011, at 3:17 PM, David Herman wrote:
Late to the party, but I've brought more booze.
On Nov 5, 2011, at 2:41 PM, Brendan Eich wrote:
We have:
1. Should an array pattern always query 'length'?
2. If the answer to (1) is no, then should ... in an array pattern query
On Nov 11, 2011, at 3:17 PM, David Herman wrote:
Late to the party, but I've brought more booze.
On Nov 5, 2011, at 2:41 PM, Brendan Eich wrote:
We have:
1. Should an array pattern always query 'length'?
2. If the answer to (1) is no, then should ... in an array pattern query
Irakli Gozalishvili wrote:
I really need to know why WeakMaps don't accept primitives as keys,
can anyone please reply ?
How would the GC know when to remove the entry from the map? Because a
primitive is never (or always, if wrapped) eligible for
garbage-collection, a WeakMap does not help
On Fri, Nov 11, 2011 at 3:28 PM, Irakli Gozalishvili rfo...@gmail.com wrote:
I really need to know why WeakMaps don't accept primitives as keys, can
anyone please reply ?
It’s because WeakMaps are intended to drop values if the key is
garbage collected.
A WeakMap guarantees that it will drop
A weak map can only remove an entry if both the key and value have died, in
many ES implementations a number of the primitives are not gc allocated and so
can never die, or are cached globally so have lifetime unrelated to any given
program.
The net effect of allowing such primitive values to
On Nov 11, 2011, at 10:22 AM, gaz Heyes wrote:
On 11 November 2011 17:13, David Herman dher...@mozilla.com wrote:
Your idea of mandatory parens is still valid (if, IMO, a bit unsatisfyingly
verbose) for most statement forms. It's only the block-statement-expression
that doesn't work. Hence
On Nov 11, 2011, at 10:25 AM, gaz Heyes wrote:
On 11 November 2011 18:01, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
var foo = {
// do stuff
100;
};
What would be the result of a labelled statement? You'd need labels to work
within expressions since you'd probably want to
Hi,
I have posted this to the long thread of Minimalist Classes, but since I have
not got any response, I assume it got lost into a long discussion. So I thought
I'll give it another try on fresh thread.
I do really liked direction that Jeremy tried to push classes to, but still I
don't
I think what I need is a map with primitive keys and non-null object values,
entries of which can be removed GC-ied if values are no longer referenced. If
I understand Map / Set / WeakMap proposals non of them can be used to solve
this issue or do I miss something ?
Regards
--
Irakli
On Nov 11, 2011, at 3:39 PM, Oliver Hunt wrote:
A weak map can only remove an entry if both the key and value have died, in
many ES implementations a number of the primitives are not gc allocated and
so can never die, or are cached globally so have lifetime unrelated to any
given program.
On Nov 11, 2011, at 11:07 AM, Allen Wirfs-Brock wrote:
On Nov 11, 2011, at 10:52 AM, Axel Rauschmayer wrote:
Got it, related to what you solve in generic classes with This-types
(covariance vs. contravariance...).
// assume |this| is the source collection
if
Thats exact port of proposal that Jeremy wrote here:
https://gist.github.com/1329619
I could write add examples from the classes proposal if that wolud help:
http://wiki.ecmascript.org/doku.php?id=harmony:classes
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue
Dave, if nesting were out of the question and monocle-mustache operator always
looked like an object literal as they currently exist, would it still be as
vile? With that form, I'm a big fan.
/Rick
On Nov 11, 2011, at 3:13 PM, David Herman dher...@mozilla.com wrote:
On Nov 11, 2011, at
A pattern of the form
[a0, a1, 〰〰, ak, ...r, bn, bn-1, 〰〰, b0]
We currently haven't specified this syntactic form. I'm not sure if it adds
enough value to justify the added conceptual complexity.
Using this pattern for accessing elements at the end would be useful. For
example:
On Nov 11, 2011, at 4:09 PM, Irakli Gozalishvili wrote:
Thats exact port of proposal that Jeremy wrote here:
https://gist.github.com/1329619
I could write add examples from the classes proposal if that wolud help:
http://wiki.ecmascript.org/doku.php?id=harmony:classes
Maybe, but I think
On Fri, Nov 11, 2011 at 4:31 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 11, 2011, at 4:09 PM, Irakli Gozalishvili wrote:
Thats exact port of proposal that Jeremy wrote here:
https://gist.github.com/1329619
I could write add examples from the classes proposal if that wolud help:
On Nov 11, 2011, at 4:42 PM, John J Barton wrote:
Object.extend() does not exist.
Which one do you mean?
Irakli is using Function.prototype.extend, not something like PrototypeJS's
Object.extend.
Similar but not identical functions
are widely used. We would like a standard form built-in
What I'm suggesting is to sugar current patterns, without adding new syntax
similar to how Funciton.prototype.bind was added. And maybe in next iteration
add special syntax if it still we be wanted. It's just so much easier to fix
`Object.extend` if it will end up to be a wrong fit than change
On Nov 11, 2011, at 3:36 PM, Allen Wirfs-Brock wrote:
On Nov 11, 2011, at 3:17 PM, David Herman wrote:
A pattern of the form
[a0, a1, 〰〰, ak, ...r]
desugars to
a0 = %v[0];
a1 = %v[1];
〰〰
ak = %v[k];
let %length = %v.length;
do we sample the length here or at the
On Nov 11, 2011, at 4:23 PM, Axel Rauschmayer wrote:
It would be nice if r was optional:
[..., b0, b1, b2] = arr
Agreed. Pure win, no downside.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Nov 11, 2011, at 4:18 PM, Rick Waldron wrote:
Dave, if nesting were out of the question and monocle-mustache operator
always looked like an object literal as they currently exist, would it still
be as vile? With that form, I'm a big fan.
I'm of multiple minds (a condition I'm gradually
[a0, a1, 〰〰, ak, ...r, bn, bn-1, 〰〰, b0]
We currently haven't specified this syntactic form. I'm not sure if it adds
enough value to justify the added conceptual complexity.
I think it's a pretty big win, and I'd argue it's totally intuitive. The
great thing about destructuring is
On Fri, Nov 11, 2011 at 4:48 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 11, 2011, at 4:42 PM, John J Barton wrote:
Object.extend() does not exist.
Which one do you mean?
I mean Object.extend does not exist.
Irakli is using Function.prototype.extend, not something like
On Nov 11, 2011, at 5:31 PM, Axel Rauschmayer wrote:
Also: we'll definitely want to allow it for splicing, so the grammar will
have to allow it already, and symmetry/consistency argue for allowing it in
destructuring too. Likewise for function formals and actuals.
Using it for splicing
While I was admiring the pros of its mutation, I overlooked how unclear it was
that a mutation was even occurring... Anyway, thanks for the clarification.
/Rick
On Nov 11, 2011, at 8:22 PM, David Herman dher...@mozilla.com wrote:
On Nov 11, 2011, at 4:18 PM, Rick Waldron wrote:
Dave, if
On Nov 11, 2011, at 5:02 PM, Irakli Gozalishvili rfo...@gmail.com wrote:
What I'm suggesting is to sugar
Sugar usually means new syntax, not methods, but no worries.
current patterns, without adding new syntax similar to how
Funciton.prototype.bind was added.
That ES5 addition was years
On Nov 11, 2011, at 5:06 PM, David Herman dher...@mozilla.com wrote:
Also: we'll definitely want to allow it for splicing,
s/splicing/spread/
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Nov 11, 2011, at 5:06 PM, David Herman wrote:
On Nov 11, 2011, at 3:36 PM, Allen Wirfs-Brock wrote:
...
We currently haven't specified this syntactic form. I'm not sure if it adds
enough value to justify the added conceptual complexity.
I think it's a pretty big win, and I'd argue
94 matches
Mail list logo
