On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where end users (engineers and
architects as well as scripters) could contribute to the developer experience
of using JavaScript
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object methods that
want the receiver when called as
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
2011/3/26 Wes Garland w...@page.ca:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users
2011/3/26 Claus Reinke claus.rei...@talk21.com:
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object
Hi,
Just a small note on
http://wiki.ecmascript.org/doku.php?id=strawman:super_in_object_initialisers
(reading currently)
Why not just to use already reserved `extends` keyword for specifying a
superclass? These XML-like braces looks not so elegant.
Coffee users the same classes syntactic
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
To
2011/3/26 Claus Reinke claus.rei...@talk21.com:
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
I've put examples of real world code chock-full of anonymous function
expressions in both leading-char (#) and angle-braketing styles here:
https://gist.github.com/67
Feel free to continue this discussion on that page, if inclined.
khs
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich
This is an interesting idea, never heard of it before. That said, it seems a
better start for brainstorming than as an end of it. The previously-mentioned
concerns about numbering being fragile seem real to me. Further, how would
this interact with eval introducing (or in some systems even
On 03/26/2011 07:44 PM, Brendan Eich wrote:
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an outer
function, the return is legal).
I might be
On Mar 26, 2011, at 9:06 PM, Jeff Walden wrote:
On 03/26/2011 07:44 PM, Brendan Eich wrote:
Non leading-char solutions have the disadvantage of using some other kind
of bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an
14 matches
Mail list logo
