RE: Extended dot notation (pick notation) proposal
On Tue Sep 20 03:38 PM, Bob Myers wrote:
>
> People in the real world continue to wonder why they can't
> pick/destructure from objects into objects, instead of just variables.
>
> http://stackoverflow.com/questions/39602360/es6-destructuring-reassign
> ment-of-object?noredirect=1#39602360
Seems like allowing to "dot" into another identifier could work:
https://tc39.github.io/ecma262/#prod-CoverInitializedName
CoverInitializedName[Yield]:
IdentifierReference[?Yield] Initializer[+In, ?Yield]
IdentifierReference[?Yield] . IdentifierName
const IDENTIFIER = 1;
const sandwichesIWantToEat = { SANDWICHES.CHEESE_STEAK, SANDWICHES.SLOPPY_JOE,
IDENTIFIER };
Use the RHS identifier as the member/property name and resolve the "dot"
expression to get the value.
const sandwichesIWantToEatResult = { CHEESE_STEAK: SANDWICHES.CHEESE_STEAK,
SLOPPY_JOE: SANDWICHES.SLOPPY_JOE, IDENTIFIER: IDENTIFIER };
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Decorators for functions
On Thu Oct 22 07:44 AM, Andreas Rossberg wrote: > > determined at creation time, allowing for massive engine optimization, > Ya I'm not sure from which hat "massive engine optimization" comes from? What's meant is likely using decorators as annotations (compile time optimizations hints): http://www.google.com/patents/US7013458 Or 'ambient decorators': https://github.com/jonathandturner/brainstorming/blob/master/README.md#c6-ambient-decorators There's 2 patterns (maybe more?): (a) Tagging a 'tree transformation' on a node. (b) Metadata at compile time on a node. The thing about (b) is it can easily live outside of the code (like in typescript where you have an optional header/declaration file) With (a), it seems more conservative to see how it gets used with classes before bolting on to functions (opinion: end result in java is not something to be proud of). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Decorators for functions
On Tue Oct 20 05:30 AM, Axel Rauschmayer wrote: > The decorator proposal does not include decorators for functions, > because it isn’t > clear how to make them work in the face of hoisting. > What's the obsession with decorators? Decorators are like saying everyone can decorate their Christmas trees. That's nice once a year but not when you start looking at all the different Christmas trees and have to maintain that stuff. Suddenly the single language you thought you understood has many dialects & philosophies. Aren't embeddable languages more interesting to learn then decorated trees? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: for statement with index and value
On Tue Jul 14 10:43 AM, Andreas Rossberg wrote: https://mail.mozilla.org/pipermail/es-discuss/2015-June/043307.html https://mail.mozilla.org/pipermail/es-discuss/2015-June/043307.html Complexity is very much a psychological aspect. And random special cases, syntactic additions, and irregularities eat into the complexity budget quickly. Fair enough, agree with that. Seems like it would be a Googly thing to objectively measure language complexity or simplicity? The complexity rank algorithm? Dismissing these things as not real problems is more history repeating itself. Love the JS conservatism Smalltalkness, less the coin tosses about perceived complexity, science wins there. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: for statement with index and value
On Mon Jul 13 10:22 PM, Kevin Smith wrote: Destructuring is here to help: for (let [index, value] of [1, 2, 3].entries()) console.log(index + : + value) The entries method returns an iterator of [index, value] pairs. Can't there be a 'key iterator' syntax? for (let value, index of [1, 2, 3]) console.log(index + : + value) let value = itOfValues.next().value; let index= itOfKeys.next().value; - An array has an implicit 'key iterator' cause there's a key for each value. - Everything else has a 'keyIteratorFrom0ToInifinity' So you have a 'value iterator' and a 'key iterator' for each thing on the RHS. Doesn't seem like much of an issue, engines just need a keyIteratorFrom0ToInifinity for non-array things cases. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: for statement with index and value
On Tue Jul 14 09:27 AM, Domenic Denicola wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew Robb Why not use the new meta syntax? If I thought this was a real problem that needed solving, Disagree As early as the mid-1980’s, it was observed that programming language research and funding emphasized technical aspects of the domain and neglected psychological aspects: The human and computer parts of programming languages have developed in radical asymmetry http://repository.cmu.edu/cgi/viewcontent.cgi?article=1805context=isr Bias of Engineering problems Psychology ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: May 2015 Meeting Notes
On Fri Jun 26 05:23 PM, Brian Terlson wrote:
https://github.com/tc39/tc39-notes/blob/master/es6/2015-05/may-29.md
Yay to Value types
and +1 for the per-realm thinking
For typeof, this would seem intuitive:
var ColorType1 = ValueType(Symbol(Color), {...});
var ColorType2 = ValueType(Symbol(Color), {...});
var ColorType3 = ValueType(Symbol(Other), {...});
var ColorType4 = ValueType(Symbol(), {...});
typeof ColorType1 // Color:s1 // where s1...sN is a generated increment/key
for a new user symbol
typeof ColorType2 // Color:s2
typeof ColorType3 // Other:s3
typeof ColorType4 // s4
// Global symbols use their keys prefixed by a 'g'
var ColorType5 = ValueType(Symbol.for(Color), {...});
typeof ColorType5 // gColor
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: May 2015 Meeting Notes
On Tue Jun 30 09:55 AM, Andreas Rossberg wrote: typeof ColorType1 // Color:s1 // where s1...sN is a generated increment/key for a new user symbol typeof ColorType2 // Color:s2 typeof ColorType3 // Other:s3 typeof ColorType4 // s4 A seemingly predictable name is a rather bad idea, because it would be very brittle, e.g., depend on other libraries loaded, or even loading order. It's better to have clearly non-deterministic (e.g. gensym) than something that pretends to be deterministic but isn't in practice. In fact, it might be best if typeof returned the symbol itself. At least that cleanly matches the generative nature of the type definition. If you want it to work cross-realm, you have to broker the symbol as usual. Can you explain how 'gensym' would be different? Google tells me: https://clojuredocs.org/clojure.core/gensym https://github.com/clojure/clojure/blob/clojure-1.5.1/src/jvm/clojure/lang/RT.java#L468 Internally I'd imagine you can represent it however you want (comparing an object pointer vs. a string), I see this more as a user-facing/illusion of simplicity thing. But anyways, understand that the intuitive thing doesn't always work out. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Are ES6 modules in browsers going to get loaded level-by-level?
On Fri Apr 24 01:35 AM, James Burke wrote:
If not natively supported in ES, it would be great to get a pointer to
the officially blessed transform of an ES module body to something
that can be bundled. Something that preserves the behaviors of the
mutable slots, and allows using the module meta.
Started using:
export in name;
export with {bundle: name}; // with {metadata object}
disclaimer: Not officially blessed by spiritum consensum
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Putting `global` reference in specs
Not so pretty but:
import * as global from “@global”;
Or some bindings:
import {Promise} from “@global”;
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark
Miller
Sent: April 17, 2015 11:53 AM
To: Glen Huang
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: Putting `global` reference in specs
This is one of several cases where, post ES6, we can provide a std module
import that provides a built-in that carries authority. Another example is the
constructor for making weak references, which necessarily provide the ability
to read a covert channel. As with shadowable globals, this module import must
be easy to virtualize. We purposely postponed this along with the Loader and
Realm API as it is security sensitive and we don't yet have enough usage
experience with modules to know how to design this separation well.
In particular, we rejected the obvious Reflect.global as it bundles the global
together with authority-free safe things, which makes virtualization of the
global alone needlessly unpleasant.
On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang
curvedm...@gmail.commailto:curvedm...@gmail.com wrote:
You guys are talking about referencing the global object in modules right?
Since in scripts you can reliably get hold of the global object by using this
in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope of a
module, I guess that means module code really isn't supposed to get hold of the
global object?
On Apr 17, 2015, at 11:34 PM, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the use strict;
makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg
rossb...@google.commailto:rossb...@google.com wrote:
On 17 April 2015 at 17:27, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the global
object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren
ann...@annevk.nlmailto:ann...@annevk.nl wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
package keyword reserved?
What's the history of the unused keyword package, is it from Java?
Been thinking about this lately, could an external module be called a package?
package/file.js
package something {
export class foo {}
}
package other {
export class foo {}
export module bar {
export class foo {}
}
}
import {foo as a} from something
import {foo as b, bar.foo} from other
/* option a) */
var api = {
foo: a,
fooOther: b,
fooBar: bar.foo
hello: function() { alert('module') };
}
export default api
/* option b) single module declaration
module apiInternalName {
import {foo} from something
import {foo as fooOther, bar.foo as fooBar} from other
function hello() { alert('module') };
}
*/
single/file.js
module barInternalName {
class foo {}
}
main.js
module api from 'package/file'
module bar from 'single/file'
Some thoughts:
- Literal modules are allowed only within packages (no module
nesting) or a single module per file
- import() semantics don't change too much (I think)
- The subtle difference is an internal module is the declaration
mechanism for exporting an api, a package is used for code organisation.
- The module pattern is optional, can import from packages directly :
index.html
script src=package/file.js/script
script
// import from package
import {foo, bar} from other;
/script
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: package keyword reserved?
On Fri Apr 11 05:52 PM, Domenic Denicola wrote: What use cases does this solve for JavaScript, not TypeScript? Not sure, benefit comes down to subjective preference. Keeps the single 'module' per file pattern from node.js Is it safe to use the 'package' keyword then, no proposals for using it? Jon ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Promise.cast and Promise.resolve
On Sun Feb 9 07:30 PM, Brendan Eich wrote:
Jonathan Bond-Caron wrote:
Thoughts on adding options/flags
Just say no.
http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html
This is a symptom. We are resisting the larger issue of do both or
design-by-
committee unioning or other such failure modes.
Fair enough, would be nice to see an alternative to:
https://github.com/apache/cordova-cli/blob/master/src/hooker.js#L155
If you multiply that pattern across many projects with different 'styles' of
writing it, complexity really adds up.
Promises.join([a,b,c]).run().then(...)// parallel
Promises.join([a,b,c]).setExecution('serial').run().then(...) // serial?
http://developer.android.com/reference/android/os/AsyncTask.html#SERIAL_EXECUTOR
As I was writing this, I saw the async proposal:
http://wiki.ecmascript.org/doku.php?id=strawman:async_functionss=async
await would be king for serial execution of animations or file system tasks.
It's all a bit confusing but going in an interesting direction,
Cheers,
J
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Promise.cast and Promise.resolve
On Fri Feb 7 12:14 PM, Tab Atkins Jr. wrote:
From a user perspective, can someone explain what chain() does?
.chain returns what is directly inside the promise, without doing any
additional
magic. This is different from .then, which flattens
promises.
For a more concrete example, assume that x is a PromisePromiseinteger.
That is, it's a promise, holding a promise, holding an integer.
x.chain(arg=arg is
a PromiseInteger), x.then(arg=arg is an Integer).
Thoughts on adding options/flags to then()?
e.g.
x.chain equivalent to x.then(promise, {unwrap: false});
Promises.all() could be similarly augmented to support serial execution.
The api signatures become ~
Promise.prototype.then ( onFulfilled , onRejected|PromiseOptions ,
PromiseOptions )
Promise.all ( iterable , PromiseIterateOptions )
Defaults:
PromiseOptions = {
unwrap: true
}
PromiseIterateOptions extends PromiseOptions {
serial: false
}
Don't have convincing use case but can pass options to then() during iteration:
Promises.all([a,b,c], {unwrap: false});
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Promise.cast and Promise.resolve
On Fri Feb 7 06:50 AM, Anne van Kesteren wrote: On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote: Sorry for knowing little about ES consensus, is this the final decision? Will you change it again? Yeah, some clarity would be nice. From a user perspective, can someone explain what chain() does? Recently hit an issue with Q.all() vs serial execution of promises: https://github.com/jbondc/cordova-plugman/commit/ad2c74b3344c8899e8ede12827f7ca4637a01b6f#diff-9f06c51911da08ebd6400ff77d629c1eR309 chain() isn't mentioned here: http://wiki.ecmascript.org/doku.php?id=strawman:concurrency Promise.all() is included in the spec but not the case for serial execution: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.all-resolve-element-functions What seems like a preferred api / pattern from an ecma PoV to serially execute promises? e.g. Promise.serial(), Promise.ordered(), Promise.follow() Is it a common enough use case to be included in the spec? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Re: Generic Bundling
On Fri Oct 25 11:48 PM, Ilya Grigorik wrote: On Fri, Oct 25, 2013 at 6:24 AM, Jonathan Bond-Caron jbo...@gdesolutions.com mailto:jbo...@gdesolutions.com wrote: I disagree, if you want to treat this as an optimization problem, let's look at it: 1. x number of resources/files 2. x number of network connections What is the optimal way of loading the resources/files? I don't have a proof but I'm pretty sure that's NP-complete. I assure you it is not NP-complete. We know what the critical resources are for the page (i.e. their priorities), and we know the properties of TCP connections (like slow-start). The optimal number of connection is 1 (with exception of few edge cases where TCP window scaling is disabled and BDP is high). Let's look at use a case: 200mb application I want to distribute over internet. The optimal number of connections is 1? You wouldn't get faster delivery with a P2P-like algorithm? e.g.: Server sends a header: Cache-clients: my-neighbor.com:4000, my-other-neighor.com:6000 Some security considerations for sure but your claim that 1 connection is optimal is bogus at best. Are you saying that HTTP 2.0 loading is the best known algorithm in all cases? That's bogus. It's certainly a better algorithm but there's a wide range of strategies that will result in faster load times (it involves bundling in some cases). Bundling does not achieve anything that a good multiplexing solution can't -- bundling is multiplexing at the application layer. HTTP 2.0 provides the necessary tools to achieve same performance as bundling, but with additional benefits of granular downloads, incremental execution, etc. (I feel like I'm stuck in a loop ;-)) That's interesting, marketing will usually say but that's just an engineering problem, engineering will say but that's just marketing. In this case, that's just at the application layer, so I'll answer that's just at the network layer. How would you suggest to deliver an application over internet (e.g. myapp.zip)? Isn't that a bundle already? I agree that delivering a single.zip makes the user wait vs. delivering images etc.. progressively. But in some cases that might be ok: - ios app (splashscreen, user waits) - android app (splashcreen, user waits) - windows 8, ... - flash, ... It depends on the use cases, bundling certainly has its advantages at the application layer. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Re: Generic Bundling
On Sun Oct 27 09:35 AM, François REMY wrote: ± How would you suggest to deliver an application over internet (e.g. ± myapp.zip)? Isn't that a bundle already? This claim is bogus. In all the cases I know, the packages are unzipped by the OS before running the application, and the application itself has no need to know anything about the package. The proof is that you can package the very same HTML app in multiple formats, and it will work for all of them. In other terms, the application layer (ECMAScript code) is unaware of the packaging layer (ZIP-based format). I don't think I'm making any bogus claim here, those are questions? My point is that distributing applications implies some level(s) of bundling. An application update could be a 'bundle' of files that has changed or single files (that change frequently). My interest is at the application layer and how this can fit with System.Loader modules. Again, I don't see why bundling and HTTP 2.0 can't co-exist. Is it possible that HTTP 2.0 just happens to optimize for the use cases that we are seeing today? Do you know what application use cases are going to occur 5 years from today? This propaganda that HTTP 2.0 is optimal for all those use cases is just wrong. If you have data or some objective proof, then please share. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Generic Bundling
On Thu Oct 10 02:22 PM, David Bruant wrote: Among other benefits [1]: pushed resources are cached individually by the browser and can be reused across many pages = It's not clear this can happen with an asset.zip Opposite benefit of using assets.zip, only a single cache entry to lookup. You should be able to re-use assets.zip across pages. Imagine having 20 images that never change in 1 year. The browser will lookup 20 cache entries, why? Use sprites? A common use case would be bundle resources that rarely change in a single file. We can discuss the deployment aspects of HTTP 2 and whether Generic Bundling as proposed can provide benefits before HTTP 2 is fully deployed, but I feel the bottleneck will be the server-side engineering to bundle the resources and this work is equivalent for both HTTP 2 and the proposed Generic Bundling. So HTTP 2 wins? It will be useful, I think of it as a win for files that change frequently. Another benefit of bundles not solved by HTTP 2: theming. http://jquery.com/themes/blue.zip http://jquery.com/themes/red.zip It would make distribution of themes much simpler. If developers point to the same 'cached' bundle from a cdn, that's a win for less internet traffic. The pattern could be: link rel=loader type=application/zip href=http://jquery.com/themes/blue.zip; ref=theme link rel=stylesheet type=text/css href=buttons.css ref=theme For backwards compatibility, you would have buttons.css available on your own the server. I think of bundling as better way of distributing applications (www or packaged), not only the performance benefits of pipelining stuff in a single request. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Generic Bundling
About Generic Bundling in: https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-09/modules.pdf script src=assets.zip$/lib/main.js/script It could be reworked as: link rel=loader type=application/zip href=assets.zip script src=lib/main.js/script Simple pattern for packaging web apps where 'assets.zip' might be already available. For remote fetching, I imagine it would block waiting for assets.zip to be available. Could be solved with something like: script src=lib/main.js ref=assets.zip/script Which would lookup link rel=loader and match ref=assets.zip to href=assets.zip Either way, I'm curious where the discussion is taking place, w3c? How does this fit with Ecmascript, System.loader? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Module literal name
On Tue Jun 25 09:34 AM, Kevin Smith wrote: import classes/foo; // use default namespace new foo.bar(); module ns from classes/foo ; // alternative namespace new ns.bar(); How is the first example any better than the second? The first is far more difficult to statically analyze, since any identifier could potentially be a namespace. It shouldn't be more difficult to statically analyse, I image that the lexer/parser would maintain a 'symbol table' of the possible variables. Some context, say I'm trying to bundle a couple of modules together for a mobile application: https://github.com/jbondc/ECMAScript/blob/master/packages/mobile.js https://github.com/jbondc/ECMAScript/blob/master/package.html Under the current proposal, what I probably would end up doing is assigning everything to the global scope anyway. I wouldn't want a developer to manually assign/import everything: module MV from classes/misc/color; module MV.color from classes/misc/color/conversion; module MV from classes/web/dom; I expanded on the idea here: https://github.com/jbondc/ECMAScript/blob/master/packages/mobile-proposal.js https://github.com/jbondc/ECMAScript/blob/master/package-proposal.html There's more comments in package-proposal.html to how I imagine it could work. Note: I have some experience with lexers/parsers but not much with JavaScript or its internals so I hope this proposal makes sense. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Module literal name
I've been experimenting with the modules definition and find it unfortunate
there's no default literal name for a module.
Could there be an optional 'namespace' or literal name within the module block?
module classes/foo {
namespace foo;
export class bar {}
}
import classes/foo; // use default namespace
new foo.bar();
module ns from classes/foo ; // alternative namespace
new ns.bar();
Some more examples here:
https://github.com/jbondc/ECMAScript/blob/master/index.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Translate hook
The loader hooks are fantastic. In the case of translate(), consider: module Button from classes/ui/Button.js module Button from classes/ui/Button.dart module Button from classes/ui/Button.ts module Button from classes/ui/Button.coffee module Button from classes/ui/Button.zip module Button from classes/ui/Button.mypackage In the last two, you can extract non-javascript content (css, html) and place it somewhere else for loading processing. It's nice to have options but would all those and more be valid by overriding Loader.translate()? IMHO, web fragmentation. I'm not sure what the problem here is supposed to be. You'll have to have libraries for doing any of these things, which will modify `Loader.translate`. Right now, I can fetch code in any language from any source, process it, and eval it. People write script tags for coffeescript or python or lua using JS translators. Is this leading to web fragmentation? If translate() is intended as a hook for transpilation, it will lead to fragmentation. I don't have crystal ball but I am concerned about 'transpilation' as a feature in the loader api. I should probably add: module Crypto from classes/crypto/Crypto.asm.js (compiled from c++) Our goal is to make the open web a compelling virtual machine, a target for compiling other languages and platforms. http://ejohn.org/blog/asmjs-javascript-compile-target/ Maybe I'm misinterpreting something, but the translate() hook just seems like a mechanism to compile just about anything that maps to javascript or LLVM bytecode. http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html Is there some consensus that the web needs typed language foo? Don't get me wrong, asm.js is really clever from a technical standpoint. I'm finding it difficult to not be worried about the non-technical implications. The second concern is re-writing code: import m from https://cdn.company.com/module.js; Can I transform the source and turn private closures into public functions? Why bother with export? Yes, you can transform anything you want, once you have the source. You can already do this with XHR, or with an inline script tag, or ... Sure but that's a bit of a stretch, XMLHttpRequest was initially designed to load XML and inline script tags are quite inconvenient for large amounts of code. By design in this case, source code transformation is encouraged either by programmers or by the browser. The reason to bother with export is that it works with the system. Sure, you can implement a whole new language, but that has exactly the costs of implementing a whole new language. The loader hooks make that possible, but it isn't reasonable to do it unless you're serving some actual use case. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
