My first post to this mailing list, so hi everyone!
I agree with Domenic, Array.fromElements would be a good name (though I
have no problem with Array.of). Just don't go with Array.new (I agree with
Rick here, it should match the constructor - Array should be no exception,
broken constructor or
On Aug 26, 2012, at 4:30 PM, Brendan Eich bren...@mozilla.com wrote:
Rick Waldron wrote:
But Array.of is not. Maybe Array.new is a good name.
Array.of is unambiguous with the current ES specification
Array.new is ok too, though -- no problem with a reserved identifier as a
property name.
On Tue, Aug 28, 2012 at 9:59 AM, Maciej Stachowiak m...@apple.com wrote:
On Aug 26, 2012, at 4:30 PM, Brendan Eich bren...@mozilla.com wrote:
Rick Waldron wrote:
But Array.of is not. Maybe Array.new is a good name.
Array.of is unambiguous with the current ES specification
Array.new
However, I'm still not quite sure what the use case is for this. For code
generation, if you know how many elements there are and what they are enough
to put them in the Array.of(...,...,...) call, why not just use
[...,...,...]? Unless it's supposed to be used for converting array-likes to
On Tue, Aug 28, 2012 at 12:40 PM, Axel Rauschmayer a...@rauschma.de wrote:
However, I'm still not quite sure what the use case is for this. For code
generation, if you know how many elements there are and what they are
enough to put them in the Array.of(...,...,...) call, why not just use
On Mon, Aug 27, 2012 at 11:38 PM, Shijun He hax@gmail.com wrote:
Example:
== my.js ==
var myLoader = new Loader(System, {fetch: myFetch}
function myFetch(relURL, baseURL, ...) {...}
myLoader.load('a/a.js', ...)
== a/a.js ==
import x from 'a/a.js' // developer means to load a/a/a.js
On Tue, Aug 28, 2012 at 7:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
As I understand, imports in a/a.js (what in this case also import
another 'a/a.js' which should be resolve to 'a/a/a.js') will also
delegate to myLoader,
Exactly.
so it is obviously wrong if myFetch is invoked
For load('a/a.js') in my.js, myFetch is invoked with:
relURL='a/a.js'
baseURL = System.baseURL = '/path/my.js'
For import x from 'a/a.js', myFetch is also invoked with:
relURL='a/a.js'
baseURL = System.baseURL = '/path/my.js'
typo, both System.baseURL should read as myLoader.baserURL
ES5 strict mode disallow Function declaration in any statements. It's
fine, but Function declaration in top labelled statements seems
harmless, why not relax the rules to allow them so we can use Labeled
Modules Specification ? Though it seems too late to fix.
Code example:
'use strict' // cause
Apologies in advance for the length...
A huge share of this complexity has been removed in recent discussions
[1]. Conclusions seem to have reach consensus on es-discuss, but nothing
has been officially accepted by TC39
As I understand it, the solution arrived at was to provide a (possibly
Shijun He wrote:
ES5 strict mode disallow Function declaration in any statements. It's
fine, but Function declaration in top labelled statements seems
harmless, why not relax the rules to allow them so we can use Labeled
Modules Specification ? Though it seems too late to fix.
It is, see
Le 28/08/2012 15:38, Kevin Smith a écrit :
Apologies in advance for the length...
Don't. We're here to discuss as the mailing-list name suggests. And if
what you need to say is long, so be it.
A huge share of this complexity has been removed in recent
discussions [1]. Conclusions
Four things:
1) The export grammar on the wiki allows:
export *;
Which I take to mean export every local binding. What's the
justification? I don't think I've ever seen a ES5 module that didn't
have some local, non-exported state or function.
2) The grammar also allows:
export *
Unique (non-private) names offer mixins without collisions. But any
general mixin utility will fail if the source object relies on privately
named methods for its functionality:
...
Neither the destination object nor the library function mixin has access
to the private name, and therefore the
Hope this isn't politically inappropriate here;-)
1. Flash is dying as a browser plugin, but otherwise still alive,
especially with compilation of Actionscript to native code [2,3].
2. Adobe has been growing support for HTML/Javascript options.
3. Actionscript is based on an old ES draft
The strawman is at
http://wiki.ecmascript.org/doku.php?id=strawman:syntactic_support_for_private_names
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Couldn’t you have the same advantages if:
- obj.@foo was syntactic sugar for obj[foo]
- @foo was syntactic sugar for [foo] (method definitions, property definitions,
etc.)
foo would be a normal variable and the following two statements would be
equivalent:
private foo;
let foo = new
Claus Reinke wrote:
Hope this isn't politically inappropriate here;-)
1. Flash is dying as a browser plugin, but otherwise still alive,
especially with compilation of Actionscript to native code [2,3].
2. Adobe has been growing support for HTML/Javascript options.
3. Actionscript is based
On Tue, Aug 28, 2012 at 8:30 PM, Brendan Eich bren...@mozilla.org wrote:
Claus Reinke wrote:
Hope this isn't politically inappropriate here;-)
1. Flash is dying as a browser plugin, but otherwise still alive,
especially with compilation of Actionscript to native code [2,3].
2. Adobe
Hi François,
Thanks so much for your thoughtful consideration of the
Object.observe() proposal. Here's my take on your counter-proposal:
Interestingly, what you've focused on is the one thing we
intentionally left out of the Object.observe() proposal, namely:
observing computed properties. In
Steve Sanderson (author of the excellent KnockoutJS framework) and
François REMY both raised the issue of observing computed properties
WRT to the Object.observe() proposal.
Having thought about this problem while helping to author
Object.observe, my thoughts are as follows:
First, I think you
21 matches
Mail list logo
