Summary:
Update Object Literal Extensions [1] to integrate with constructor
parameters for concise instance initialization.
Details:
function f (a, !~this.b, this.c:= 1) {
g(a);
}
// results in f's [[Construct]] ( but not [[Call]] ) behaving like:
function f (a, b, c = 1) {
I sent out a separate proposal for just the concise instance
initialisation part which is relevant to any constructor, not just
classes. I'll work on the classes integration separately.
On Fri, May 20, 2011 at 5:00 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On May 20, 2011, at 10:36
this.c:= 1 looks like an error. If the intent was to set the c property to
a constant, it should not be a function' parameter. If, as I understood, you
have set a default value for the c parameter, what if you didn't specify
that value? I think it shows that the current 'readonly' syntax (aka
At the very bottom, there is a note that says:
With GLR parsing for the spec grammar, we could consider, e.g. (x) {x} instead
of {|x| x} with *LineTerminator* excluded between parameters and body.
FWIW, Speaking from a developers perspective, the syntax: (x){x} , has a
very familiar voice that
On May 21, 2011, at 7:31 AM, Rick Waldron wrote:
At the very bottom, there is a note that says:
With GLR parsing for the spec grammar, we could consider, e.g. (x) {x}
instead of {|x| x} with LineTerminator excluded between parameters and body.
FWIW, Speaking from a developers
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a paren-free call syntax
Why is that essential?
The argument, as I understand it from Smalltalk, Ruby, and E experts, is
On May 21, 2011, at 7:56 AM, Rick Waldron wrote:
Brendan,
Thanks for the clarification on that.
I've been following the shorter function syntax discussions pretty closely,
as well as reading the strawman proposals, so please forgive me if this has
been addressed or refuted.
Given
On Sat, May 21, 2011 at 7:43 AM, Brendan Eich bren...@mozilla.com wrote:
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a paren-free call syntax
Why is that essential?
When I
On Sat, May 21, 2011 at 7:56 AM, Rick Waldron waldron.r...@gmail.com wrote:
Brendan,
Thanks for the clarification on that.
I've been following the shorter function syntax discussions pretty closely,
as well as reading the strawman proposals, so please forgive me if this has
been addressed or
Alex,
That is not what I wrote at all because I didn't write the it could be better.
The analogy that Nathan was making does not apply to JavaScript. He
wrote that C# delegates were not popular in C# 2.0. Functions are
already popular in JavaScript.
Peter
On Sat, May 21, 2011 at 10:25 AM,
On 21/05/2011, at 16:43, Brendan Eich wrote:
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a paren-free call syntax
Why is that essential?
The argument, as I understand it
I personnaly agree that it works, we don't need to change
it is a bad pattern, but you still have to prove your propo-
sal is really better. Based on the number of mails we have
seen in this mailing list saying they didn't want to see this
implemented as-is, I think we can say it is (or, at
On May 21, 2011, at 10:32 AM, Peter Michaux wrote:
Alex,
That is not what I wrote at all because I didn't write the it could be
better.
It could be shorter.
The analogy that Nathan was making does not apply to JavaScript. He
wrote that C# delegates were not popular in C# 2.0. Functions
On May 21, 2011, at 9:50 AM, Peter Michaux wrote:
On Sat, May 21, 2011 at 7:43 AM, Brendan Eich bren...@mozilla.com wrote:
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a
On Sat, May 21, 2011 at 10:46 AM, Brendan Eich bren...@mozilla.com wrote:
Saying JS has function expressions that are wildly popular is jumping to a
conclusion.
How is that jumping to conclusions? All the JavaScript code that I
read uses function expressions.
JS is popular in that it's the
On May 21, 2011, at 10:38 AM, Jorge wrote:
On 21/05/2011, at 16:43, Brendan Eich wrote:
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a paren-free call syntax
Why is that
On Sat, May 21, 2011 at 10:50 AM, Brendan Eich bren...@mozilla.com wrote:
On May 21, 2011, at 9:50 AM, Peter Michaux wrote:
In another thread, some people were suggesting {||}
as an exact alternative to the thin arrow.
Yes, I cited the thread in the strawman. So what? Chopping proposals into
On May 21, 2011, at 10:05 AM, Peter Michaux wrote:
On Sat, May 21, 2011 at 7:56 AM, Rick Waldron waldron.r...@gmail.com wrote:
Brendan,
Thanks for the clarification on that.
I've been following the shorter function syntax discussions pretty closely,
as well as reading the strawman proposals,
On Sat, May 21, 2011 at 10:38 AM, Jorge jo...@jorgechamorro.com wrote:
Why the (sudden) urge to copy so many bits ( paren-free, - // =, etc ) of
coffee's syntax ?
I agree. I don't see how Coffeescript deserves to be such a strong
influence with such a short history and limited use.
(does JS
On Sat, May 21, 2011 at 11:09 AM, Brendan Eich bren...@mozilla.com wrote:
'lambda' is not reserved and still overlong. TC39 and this list have been
over this ground before. I don't see anything new in your post to change the
outcome.
TC39 will not introduce *any* new keywords to the
On May 21, 2011, at 11:01 AM, Peter Michaux wrote:
On Sat, May 21, 2011 at 10:46 AM, Brendan Eich bren...@mozilla.com wrote:
Saying JS has function expressions that are wildly popular is jumping to a
conclusion.
How is that jumping to conclusions? All the JavaScript code that I
read
On May 21, 2011, at 11:12 AM, Peter Michaux wrote:
On Sat, May 21, 2011 at 10:38 AM, Jorge jo...@jorgechamorro.com wrote:
Why the (sudden) urge to copy so many bits ( paren-free, - // =, etc ) of
coffee's syntax ?
I agree. I don't see how Coffeescript deserves to be such a strong
On May 21, 2011, at 11:16 AM, Peter Michaux wrote:
On Sat, May 21, 2011 at 11:09 AM, Brendan Eich bren...@mozilla.com wrote:
'lambda' is not reserved and still overlong. TC39 and this list have been
over this ground before. I don't see anything new in your post to change the
outcome.
On Sat, May 21, 2011 at 11:20 AM, David Herman dher...@mozilla.com wrote:
Previously, you argued against the importance syntactic convenience, but it
seems what you really were opposed to was a new function form that wasn't a
true lambda. But now that there is one back on the table, you're OK
On May 21, 2011, at 11:07 AM, Peter Michaux wrote:
On Sat, May 21, 2011 at 10:50 AM, Brendan Eich bren...@mozilla.com wrote:
On May 21, 2011, at 9:50 AM, Peter Michaux wrote:
In another thread, some people were suggesting {||}
as an exact alternative to the thin arrow.
Yes, I cited the
On Sat, May 21, 2011 at 11:36 AM, Brendan Eich bren...@mozilla.com wrote:
What part of integrated design was unclear?
None of it.
If somehow the whole is rejected, we can pluck out parts and propose them
separately, or better: as part of alternative integrated designs.
Understood.
Neither
On May 21, 2011, at 11:54 AM, Peter Michaux wrote:
On Sat, May 21, 2011 at 11:36 AM, Brendan Eich bren...@mozilla.com wrote:
If somehow the whole is rejected, we can pluck out parts and propose them
separately, or better: as part of alternative integrated designs.
Understood.
Neither
For http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival I have
written up the Ruby-inspired {|x| x * x} syntax.
Alternatives (ignoring keyword issues) that look more like function syntax
(Peter's suggestion of lambda (x) { x * x }, e.g.) seem worse in this light:
block lambdas
On May 21, 2011, at 12:37 PM, Brendan Eich wrote:
For http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival I
have written up the Ruby-inspired {|x| x * x} syntax.
Alternatives (ignoring keyword issues) that look more like function syntax
(Peter's suggestion of lambda (x) {
On Sat, May 21, 2011 at 10:43 AM, Brendan Eich bren...@mozilla.com wrote:
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a paren-free call syntax
Why is that essential?
The
I very much want short functions. However, the semantics of
JavaScript lambdas are so wonderfully simple.
Adding a semantically different callable thing is a huge mistake, in
my opinion. I'd love to be able to write
{|a, b, c| a + b * c }
or even
(a, b, c) - { a + b * c }
or
On May 21, 2011, at 4:23 PM, Jon Zeppieri wrote:
On Sat, May 21, 2011 at 10:43 AM, Brendan Eich bren...@mozilla.com wrote:
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a
On May 21, 2011, at 5:28 PM, Isaac Schlueter wrote:
function (a, b, c) { return a + b * c }
but I really don't want to replace our existing simple semantics.
Nothing is replaced.
You mean adding new semantics for new syntax is like replacing current
semantics with current + new, which
On Sat, May 21, 2011 at 8:54 PM, Brendan Eich bren...@mozilla.com wrote:
On May 21, 2011, at 4:23 PM, Jon Zeppieri wrote:
I'm just not clear on how that relates to the downward funargs point.
It doesn't. Two separate points. Sorry, I should have used a bulleted list or
something :-P.
On May 21, 2011, at 5:56 PM, Brendan Eich wrote:
On May 21, 2011, at 5:28 PM, Isaac Schlueter wrote:
function (a, b, c) { return a + b * c }
but I really don't want to replace our existing simple semantics.
Nothing is replaced.
You mean adding new semantics for new syntax is like
On May 21, 2011, at 6:13 PM, Alex Russell wrote:
On May 21, 2011, at 5:56 PM, Brendan Eich wrote:
On May 21, 2011, at 5:28 PM, Isaac Schlueter wrote:
function (a, b, c) { return a + b * c }
but I really don't want to replace our existing simple semantics.
Nothing is replaced.
You
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
I like it. Blocks seem like “true” functions, where current functions always
carry the method-ish |this| with them. Blocks are especially useful as a
concise callable construct inside methods.
Questions:
- |this|: How is
On Sat, May 21, 2011 at 1:24 PM, Brendan Eich bren...@mozilla.com wrote:
It turns out now that it's really a dilemma what to choose -- arrows or
blocks... have to think.
Arrow function syntax is just syntax. I will drop it if we can agree on
block lambda revival. As @_sjs (Sami Samhuri)
38 matches
Mail list logo
