Re: Finding a "safety syntax" for classes

On Fri, Mar 23, 2012 at 1:38 AM, Brendan Eich wrote: > 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 month

Re: Finding a "safety syntax" for classes

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 you

Re: Full Unicode based on UTF-16 proposal

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 f

Re: Finding a "safety syntax" for classes

On Fri, Mar 23, 2012 at 12:30 AM, Brendan Eich 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 declaration/statement

Re: Finding a "safety syntax" for classes

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'

Re: clojure like protocols

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

Re: Finding a "safety syntax" for classes

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

Re: Finding a "safety syntax" for classes

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 __

Re: Finding a "safety syntax" for classes

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 hoisting

Re: Finding a "safety syntax" for classes

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 https://mail.mozilla.org/list

Re: simpler, sweeter syntax for modules

John J Barton wrote: On Thu, Mar 22, 2012 at 4:54 PM, Brendan Eich 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 t

Re: clojure like protocols

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 > "implementatio

Re: simpler, sweeter syntax for modules

On Thu, Mar 22, 2012 at 4:54 PM, Brendan Eich 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

Re: clojure like protocols

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

Re: UUIDs?

2012/3/22 Mark S. Miller > On Thu, Mar 22, 2012 at 10:20 AM, 程劭非 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 gene

Re: simpler, sweeter syntax for modules

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. 1. We are not breaking run-to-completion by nesting (conditionally on control flow) blocking event l

Re: simpler, sweeter syntax for modules

On Thu, Mar 22, 2012 at 3:06 PM, Sam Tobin-Hochstadt wrote: > On Thu, Mar 22, 2012 at 5:11 PM, John J Barton > 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 mea

Re: simpler, sweeter syntax for modules

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'

Re: simpler, sweeter syntax for modules

On Thu, Mar 22, 2012 at 5:11 PM, John J Barton 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 case: let $; system.l

clojure like protocols

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 shar

Re: simpler, sweeter syntax for modules

On Thu, Mar 22, 2012 at 1:54 PM, Brendan Eich 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 > http://wiki

Re: simpler, sweeter syntax for modules

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.

Re: simpler, sweeter syntax for modules

On Mar 22, 2012, at 9:06 AM, Andreas Rossberg wrote: > On 22 March 2012 16:30, David Herman wrote: > > No exports from a Program. > > Except that the syntax currently includes that. ;-) Oops. Fixed. > I assumed this is because you want to parse an external module as a program. No, it's becau

Re: simpler, sweeter syntax for modules

On Thu, Mar 22, 2012 at 10:32 AM, Brendan Eich 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

Re: UUIDs?

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, 程劭非 wrote: > Random number in big enough range could replace uuid in most cases. > But it's still not tru

Re: UUIDs?

On Thu, Mar 22, 2012 at 10:20 AM, 程劭非 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 make sure? How

Re: simpler, sweeter syntax for modules

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

Re: simpler, sweeter syntax for modules

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 __

Re: simpler, sweeter syntax for modules

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 significa

Re: Finding a "safety syntax" for classes

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

Re: Finding a "safety syntax" for classes

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:gener

Re: simpler, sweeter syntax for modules

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,

Re: simpler, sweeter syntax for modules

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

Re: simpler, sweeter syntax for modules

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 defining/as

Re: UUIDs?

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. B

Re: simpler, sweeter syntax for modules

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

Re: Finding a "safety syntax" for classes

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 "

Re: const initializers: once more unto the breach

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, regardl

Re: UUIDs?

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

Re: Finding a "safety syntax" for classes

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

RE: simpler, sweeter syntax for modules

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 questio

Re: const initializers: once more unto the breach

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 k

Re: simpler, sweeter syntax for modules

On 22 March 2012 16:30, David Herman 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. ;-) I

Re: simpler, sweeter syntax for modules

On Wed, Mar 21, 2012 at 11:33 PM, Brendan Eich 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

Re: simpler, sweeter syntax for modules

On Mar 22, 2012, at 4:48 AM, Andreas Rossberg wrote: > On 22 March 2012 07:33, Brendan Eich 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, when this is a

Re: simpler, sweeter syntax for modules

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 https://mail.m

Re: Harmony helpwanted: Proxy, Map discrepancy between V8 and SpiderMonkey

On 21 March 2012 21:00, Alex Vincent 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 that proxy throu

Re: simpler, sweeter syntax for 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 o

Re: simpler, sweeter syntax for modules

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 > mod

Re: simpler, sweeter syntax for modules

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:

RE: simpler, sweeter syntax for modules

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 abun

Re: simpler, sweeter syntax for modules

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 giv

Re: simpler, sweeter syntax for modules

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. I don't think it is worth bending the notion of module like

Re: simpler, sweeter syntax for modules

On 22 March 2012 07:33, Brendan Eich 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 f

Re: simpler, sweeter syntax for modules

On 22 March 2012 07:12, David Herman 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. Desp

Re: simpler, sweeter syntax for modules

On 22 March 2012 02:35, David Herman 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 just define

Re: simpler, sweeter syntax for modules

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 dyn

Re: UUIDs?

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 : > Wrong list, sorry about that :) > > > On Thu, Mar 15,

Re: simpler, sweeter syntax for modules

On 22 March 2012 10:23, Peter van der Zee wrote: > On Wed, Mar 21, 2012 at 11:28 PM, David Herman > wrote: > > * importing with renaming: > > > >import { draw: drawGun }from "cowboy.js", > > { draw: drawWidget } from "widgets.js"; > > > > The brackets don't seem necessary (at l

Re: simpler, sweeter syntax for modules

On Wed, Mar 21, 2012 at 11:28 PM, David Herman 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? import draw:

Re: const initializers: once more unto the breach

On 21 March 2012 20:05, 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, absolut

Re: simpler, sweeter syntax for modules

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 expe