So, is that's all? Anyone else thinks it's a needed thing in the ES?
On 22.08.2011 14:57, Dmitry A. Soshnikov wrote:
On 22.08.2011 12:47, Irakli Gozalishvili wrote:
I'm very much interested in getting something like this! In fact I
have been useing similar documentation style for some time
We are currently in the process of implementing block scoping for V8
(http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings).
Brendan and Dave suggest that certain combinations of `let' and `var'
should be an error (more precisely, a syntax error, I assume).
However, there are
I'm in favor of letting let shadow var, but having a var declaration
within a let's scope be a error. I see this as being the most compatible
when working in global scope (and concatenating files). I suspect that most
new code will quickly move to using let everwhere.
On Tue, Aug 23, 2011 at
A convenient notation for multiline documentation comments, with convenient
reflection (*not* via toString() scraping!), would be a fine thing.
Some of the design dimensions:
0. Comment vs. string / quasiliteral?
1. function-only, or object literal too -- or any declaration?
2. Before
On Aug 23, 2011, at 5:31 AM, Andreas Rossberg wrote:
We are currently in the process of implementing block scoping for V8
(http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings).
The wiki page spec. is neither complete nor up to date so I wouldn't depend too
much on what it
The rough convention we were following for ES5 was that Object.* functions that
were expected to be used in application layer code had short imperative names
like keys, create, freeze, etc. Functions that were expected to be primarily
used in meta layers of framework or other reflective
On Aug 23, 2011, at 5:31 AM, Andreas Rossberg wrote:
However, there are various possibilities to interpret this. Assume
that each line in the following is a function scope:
{ let x; var x } // 1a
{ var x; let x } // 1b
{ let x; { var x } } // 2a
{ var x; { let x } } // 2b
{ { let
On 23.08.2011 20:54, Brendan Eich wrote:
A convenient notation for multiline documentation comments, with convenient
reflection (*not* via toString() scraping!), would be a fine thing.
Yes, exactly this -- help(...) function, and also good auto-complete of
object methods helped me some time
On 23.08.2011 21:32, Allen Wirfs-Brock wrote:
The rough convention we were following for ES5 was that Object.* functions that
were expected to be used in application layer code had short imperative names
like keys, create, freeze, etc. Functions that were expected to be primarily
used in meta
On Aug 9, 2011, at 1:03 PM, Dmitry A. Soshnikov wrote:
And what about this method Object.getMethods(...),
Object.getMethodNames(...). Do we need it? I think it can be useful (since
methods can be non-enumerable, and Object.keys(...) won't help, and after
Object.getOwnPropertyNames(...)
On 8/23/11 at 9:54, bren...@mozilla.com (Brendan Eich) wrote:
2. Before function, a la javadoc comments, or first thing in body, a la the
prologue directive idea?
I have found it difficult to read a Java program from top to
bottom because the javadoc comments proceed the function/method
On 24.08.2011 0:39, Allen Wirfs-Brock wrote:
On Aug 9, 2011, at 1:03 PM, Dmitry A. Soshnikov wrote:
And what about this method Object.getMethods(...),
Object.getMethodNames(...). Do we need it? I think it can be useful
(since methods can be non-enumerable, and Object.keys(...) won't
help,
On Aug 9, 2011, at 2:05 PM, Dmitry A. Soshnikov wrote:
On 24.08.2011 0:39, Allen Wirfs-Brock wrote:
I'm don't really see the that they are needed enough to build these in when
they can be synthesized pretty easily. What is the justification for these
and not others such as
13 matches
Mail list logo
