On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in the
first place, since he felt programmers would get confused that it was a dynamic
assignment
On Mar 21, 2012, at 9:41 PM, Brendan Eich wrote:
Perhaps Python has the right syntax, then?
from foo.js import foo;
import foo.js as Foo;
I suppose we could. I always thought this was an awkward choice on Python's
part. The first line always reminds me of the Yinglish constructions my
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in the
first place, since he felt programmers would get confused that it was a
On Mar 21, 2012, at 3:28 PM, David Herman wrote:
* importing with renaming:
import { draw: drawGun }from cowboy.js,
{ draw: drawWidget } from widgets.js;
Hey Dave,
This all looks really nice! - the only thing that threw me was the export
rename – I intuitively expect the
On 21 March 2012 20:05, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 21, 2012, at 10:11 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
Right, but my comment was only about checking of assignments to const
variables. Those are always an error, regardless of TDZ behaviour.
On Wed, Mar 21, 2012 at 11:28 PM, David Herman dher...@mozilla.com wrote:
* importing with renaming:
import { draw: drawGun } from cowboy.js,
{ draw: drawWidget } from widgets.js;
The brackets don't seem necessary (at least not from a parsing
perspective). Maybe drop them?
On 22 March 2012 10:23, Peter van der Zee e...@qfox.nl wrote:
On Wed, Mar 21, 2012 at 11:28 PM, David Herman dher...@mozilla.com
wrote:
* importing with renaming:
import { draw: drawGun }from cowboy.js,
{ draw: drawWidget } from widgets.js;
The brackets don't seem
UUID is not only a random Number or String. It has to contain time and
position to make itself unique in the world.
It looks Math.random is related to time. We have no way to involve
position information to JS currently.
2012/3/16 Nuno Job nunojobpi...@gmail.com:
Wrong list, sorry about that :)
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it
in the first place, since he felt programmers would get confused that
it was a
On 22 March 2012 02:35, David Herman dher...@mozilla.com wrote:
Follow-up: I've factored out these two alternative approaches, both of
which I think are defensible.
Grammars:
http://wiki.ecmascript.org/doku.php?id=harmony:modules#syntax
Nice! One question: is there a reason why you not
On 22 March 2012 07:12, David Herman dher...@mozilla.com wrote:
On Mar 21, 2012, at 9:01 PM, Axel Rauschmayer wrote:
I like variant B, because it follows the rules:
- module = define a module
- import = extract something out of a module
As Dave already mentioned, that is my stance, too.
On 22 March 2012 07:33, Brendan Eich bren...@mozilla.org wrote:
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in
the first
This is great stuff. I've got a quick question about the `as` keyword.
import 'foo.js' as Foo;
Is there any reason we can't simply do
var Foo = import 'foo.js';
When looking for the source of a variable, I often search for /Foo =/ to
discern it's origin and it only seems natural that giving
Callable modules are a hugely important use case. jQuery and Underscore spring
to mind. I’ve made one myself [1].
Also important: what about construct-able modules? Or to put it another way,
what about exporting a module that is a class? Examples from Node [2] [3] and
Node-land [4] [5] are
Correct me if I have any of this wrong, but modules don't need to be
callable for the jQuery use case:
// jquery.js
export function $(...) { ... }
// program.js
import $ from path/to/jquery.js;
$(#elem).whatever
We don't need node style modules-as-classes either:
//
On Mar 22, 2012, at 4:55 AM, Andreas Rossberg wrote:
One point that I haven't seen mentioned yet (and it is unrelated to syntax):
export call makes me cringe -- making modules callable is not just weird,
it seems completely future-hostile to the possibility of having parameterized
modules.
That said, it requires no more code to say:
// jquery.js
export function $(selector) { ... }
...
// client
import $ from jquery.js;
let elements = [foo, bar, baz].map($);
$(quux).style(...);
So maybe people have over-sold the importance of callable modules. In
On 21 March 2012 21:00, Alex Vincent ajvinc...@gmail.com wrote:
https://www.alexvincent.us/temp/ProxyCtor/V8-SpiderMonkey-test.html
I reduced the testcase quite severely. It's a combination between Proxy
and WeakMap. I store the proxy as a key for the WeakMap, and then expect
to get back
On Mar 22, 2012, at 4:46 AM, Andreas Rossberg wrote:
Nice! One question: is there a reason why you not just define
Program ::= ModuleBody
?
No exports from a Program.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
On Mar 22, 2012, at 4:48 AM, Andreas Rossberg wrote:
On 22 March 2012 07:33, Brendan Eich bren...@mozilla.org wrote:
But why make misleading syntax? More of a question for John: why write
|load(bar.js)| there, looking for all the world like a function call
evaluated in order at runtime,
On Wed, Mar 21, 2012 at 11:33 PM, Brendan Eich bren...@mozilla.org wrote:
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in the
On 22 March 2012 16:30, David Herman dher...@mozilla.com wrote:
On Mar 22, 2012, at 4:46 AM, Andreas Rossberg wrote:
Nice! One question: is there a reason why you not just define
Program ::= ModuleBody
?
No exports from a Program.
Except that the syntax currently includes that.
Allen Wirfs-Brock wrote:
On Mar 21, 2012, at 10:11 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
Right, but my comment was only about checking of assignments to const
variables. Those are always an error, regardless of TDZ behaviour.
Agreed, absolutely. In all-strict code we know
The bracket syntax is pretty confusing with object literal notation imo.
It shouldn't be too confusing, and the similarity is in fact intentional.
You should read import as destructuring (and export as the inverse
structuring, if you want).
I agree that this isn't really a question
I've created a strawman proposal for Russell's class safety syntax:
http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
What does time or position have to do with uniqueness? Why not velocity,
spin and charm? Seriously, given a good source of entropy, a large enough
random number is globally unique.
Math.random() is not a good source of entropy, but crypto.getRandomValues
is. See
On Mar 22, 2012, at 9:10 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Mar 21, 2012, at 10:11 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
Right, but my comment was only about checking of assignments to const
variables. Those are always an error, regardless of TDZ
Looks great. A couple of questions (I may have missed something):
1.) What is a generator method?
*PropertyName ( FormalParameterList? ) { FunctionBody } // generator
method
2.) What happens if the AssignmentExpression to the right of extends
evaluates to something that doesn't have a
Andreas Rossberg wrote:
I still wonder why you think it is so confusing to use the equality
sign for module bindings. It is overloaded to mean define as and
assign in almost all language that use it for the latter, and for
different semantic categories, too. I never witnessed anybody being
Random number in big enough range could replace uuid in most cases.
But it's still not truely unique.
In specified time and specified position(specified device), you can
make sure there is only one uuid generated.
BTW, we are using crypto.getRandomValues in our project, it works well
until now.
David Herman wrote:
The 'at' might be appropriate but it just looks like an unfinished
thought: the module foo at 'foo.js' ...what? Both the import-as and
module-= forms state what the declaration is doing. The former
declares it is importing the module; the latter declares it is
John J Barton wrote:
I guess you mean: a special form evaluated before the outer function
runs? Surely this form is not off-line.
No, before anything in the containing Program (up to the script
container) runs. Modules are prefetched, not loaded by a nested event
loop that violates
On Mar 22, 2012, at 9:12 AM, Luke Hoban wrote:
The bracket syntax is pretty confusing with object literal notation imo.
It shouldn't be too confusing, and the similarity is in fact intentional.
You should read import as destructuring (and export as the inverse
structuring, if you want).
On Mar 22, 2012, at 10:05 AM, Kevin Smith wrote:
Looks great. A couple of questions (I may have missed something):
1.) What is a generator method?
*PropertyName ( FormalParameterList? ) { FunctionBody } // generator
method
http://wiki.ecmascript.org/doku.php?id=harmony:generators
Ah - knew I'd missed something completely obvious - thanks!
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Luke Hoban wrote:
At least half the times I've shown object destructuring or module import renaming syntax
I've gotten don't you have that backwards? remarks. I can't say I have a
better recommendation for the general object destructuring syntax, but I expect this to
be a point of
Allen Wirfs-Brock wrote:
I also find myself getting it backwards, but it helps me to remember that for
destructing assignment the target needs to be an arbitrary LHS which won't
really fit well to the right of the :
You mean left, not right. ;-)
/be
On Mar 22, 2012, at 10:56 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I also find myself getting it backwards, but it helps me to remember that
for destructing assignment the target needs to be an arbitrary LHS which
won't really fit well to the right of the :
You mean left, not
On Thu, Mar 22, 2012 at 10:20 AM, 程劭非 csf...@gmail.com wrote:
Random number in big enough range could replace uuid in most cases.
But it's still not truely unique.
In specified time and specified position(specified device), you can
make sure there is only one uuid generated.
How do you
I agree, UUID's are becoming increasingly more useful for applications as
apps need quick and unique identifiers to send back and form relationships
between data.
On Thursday, March 22, 2012, 程劭非 csf...@gmail.com wrote:
Random number in big enough range could replace uuid in most cases.
But
On Thu, Mar 22, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.org wrote:
John J Barton wrote:
I guess you mean: a special form evaluated before the outer function
runs? Surely this form is not off-line.
No, before anything in the containing Program (up to the script container)
runs.
John J Barton wrote:
Second, we need a solution for asynchronous loading with run-time
selection. We use it now and as we move to much better network layers
we will use it a lot more.
Of course. This is what the
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders API is all
about.
On Thu, Mar 22, 2012 at 1:54 PM, Brendan Eich bren...@mozilla.org wrote:
John J Barton wrote:
Second, we need a solution for asynchronous loading with run-time
selection. We use it now and as we move to much better network layers
we will use it a lot more.
Of course. This is what the
I have published a [blog post] about JS [protocol library] that implements
clojure like polymorphism, which is interesting
as it solves typical [problems with classes]. From my experiment I got a
feeling that it may be a much better feet for JS language than classes, so I
thought it's worth
On Thu, Mar 22, 2012 at 5:11 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
The module solution posted seems to have a top-notch solution for the
static case but the dynamic case is buried in the loader.
I don't really understand what you mean by buried in the loader.
Here's the dynamic
Btw, another question that has bugged me lately: with 1JS, what
happens when I do a sloppy-mode direct eval on a program string
containing a module declaration? In global scope? In local scope?
It's a good question, and one I've thought about some. This could
use some whiteboard time -- let's
On Thu, Mar 22, 2012 at 3:06 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Thu, Mar 22, 2012 at 5:11 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
The module solution posted seems to have a top-notch solution for the
static case but the dynamic case is buried in the loader.
I
2012/3/22 Mark S. Miller erig...@google.com
On Thu, Mar 22, 2012 at 10:20 AM, 程劭非 csf...@gmail.com wrote:
Random number in big enough range could replace uuid in most cases.
But it's still not truely unique.
In specified time and specified position(specified device), you can
make sure
Maye I'm crazy but this seems like IDL in a more JavaScript friendly form.
Not just WebIDL JavaScript semantics and types friendly, but targeted
at implementation using JavaScript which is less friendly and requires
Proxy wrappers for many/most things like dom.js does. Which is a good thing
and I
On Thu, Mar 22, 2012 at 4:54 PM, Brendan Eich bren...@mozilla.org wrote:
John J Barton wrote:
If I go back to my previous question, can we understand what should happen
here?
if (version === 1)
import y from 'lib1.js';
else
import y from 'lib2.js';
Again, no.
No, we can't understand
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Thursday, 2012-03-22 at 17:09 , Brandon Benvie wrote:
Maye I'm crazy but this seems like IDL in a more JavaScript friendly form.
Not just WebIDL JavaScript semantics and types friendly, but targeted at
implementation
John J Barton wrote:
On Thu, Mar 22, 2012 at 4:54 PM, Brendan Eichbren...@mozilla.org wrote:
John J Barton wrote:
If I go back to my previous question, can we understand what should happen
here?
if (version === 1)
import y from 'lib1.js';
else
import y from 'lib2.js';
Again, no.
No,
Since the method name is specified as PropertyName, it will allow bracketed
expressions for names, correct?
class A {
[maybePrivateMethod]() {
...
}
}
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
David Herman wrote:
I do think that class declarations should be hoisted, both in the
sense of being in scope for the whole containing block (as with let
and function) and in the sense of being initialized before the block
begins executing (as with function).
Allen has argued against
Rick Waldron wrote:
I've taken my previous tri-lambda-syntax support example
(https://gist.github.com/2013909) and I've updated the code to use
your proposed class syntax... It looks nice:
https://gist.github.com/2139330
This is sweet! Even without the thin-arrow function expression.
/be
Russell Leggett wrote:
Well, I favour constructor because it blends well with the
underlying mechanics... there _is_ a property named constructor in
a prototype, pointing exactly to the constructor method of that
prototype. So if I looks at the class {...} block as a blueprint
Yeah that's what I was trying to say. This is suited towards use in
JavaScript whereas IDL isn't.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich wrote:
Allen has argued against hoisting, based on the extends clause being
an evaluated expression.
Also (if included) based on static property initializers being
evaluated, intuitively in declaration/statement order, but if you hoist
the class when do you evaluate the statics'
On Fri, Mar 23, 2012 at 12:30 AM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
Allen has argued against hoisting, based on the extends clause being an
evaluated expression.
Also (if included) based on static property initializers being evaluated,
intuitively in
I've updated the proposal based on the feedback received so far. Changes are
listed in the Updates section.
http://norbertlindenberg.com/2012/03/ecmascript-supplementary-characters/
Norbert
On Mar 16, 2012, at 0:18 , Norbert Lindenberg wrote:
Based on my prioritization of goals for support
Russell Leggett wrote:
This is what Allen said about hoisting for this spec (Its been a long
thread, not sure if you missed this.):
Thanks, I did catch up that far on the thread, but Allen reiterated the
point he'd made months ago: you can't hoist *and initialize* the class
declaration as
61 matches
Mail list logo
