Yes, exactly.
Of course, running a module can load other modules using the Loaders API,
but that doesn't add any new imports or exports to the module itself.
Sam
On Nov 18, 2013 8:54 AM, "Brian Di Palma" wrote:
> You can statically analyze the module text and enumerate the complete
> imports an
You can statically analyze the module text and enumerate the complete
imports and exports of the module without having to execute the module. The
execution of the module will not dynamically increase it's imports/exports.
For instance could you have a Math.random that decides if a dependency is
re
On Nov 18, 2013 7:17 AM, "Brian Di Palma" wrote:
>
> Correct me if I'm wrong David but module import/exports are not
> dynamic which allows tooling/IDEs to be more intelligent and
> programmers to easily understand what dependencies a module
> has/provides?
Yes, that's correct, if I guess correct
Correct me if I'm wrong David but module import/exports are not
dynamic which allows tooling/IDEs to be more intelligent and
programmers to easily understand what dependencies a module
has/provides?
On Sat, Nov 16, 2013 at 8:30 AM, David Herman wrote:
> On Nov 16, 2013, at 3:32 AM, John Barton w
On Sun, Nov 17, 2013 at 2:23 PM, Matthew Robb wrote:
> I like it. If there is a desire to stay closer to
>> Is the value of `src` a module ID or a path? How about when packages are
>> used (for bundling)? Is there a way to combine module IDs and packages?
>
> For the most part the answer to these kinds of questions is that we support
> "all of the above," but I'd like to wait just a little bit long
On Nov 17, 2013, at 11:59 AM, Axel Rauschmayer wrote:
> On Nov 17, 2013, at 6:14 , David Herman wrote:
>
>>> Does this imply ?
>>
>> Works either way, inline or external. (Requiring src="" is one of the
>> reasons why
On Nov 17, 2013, at 6:14 , David Herman wrote:
>> Does this imply ?
>
> Works either way, inline or external. (Requiring src="" is one of the reasons
> why
I like it. If there is a desire to stay closer to
<3 this, it matches my go-back-to-1995 dreams.
/be
> On Nov 16, 2013, at 9:14 PM, David Herman wrote:
>
>> On Nov 16, 2013, at 7:54 AM, Matthew Robb wrote:
>>
>> Does this imply ?
>
> Works either way, inline or external. (Requiring src="" is one of the reasons
> why
On Nov 16, 2013, at 7:54 AM, Matthew Robb wrote:
> Does this imply ?
Works either way, inline or external. (Requiring src="" is one of the reasons
why
Does this imply ?
On Sat, Nov 16, 2013 at 12:30 AM, David Herman wrote:
> On Nov 16, 2013, at 3:32 AM, John Barton wrote:
>
> > Could someone help me understand why two goals for parsing JS is a good
> thing?
>
> Hm, it sounds like you've assumed a conclusion already. Let me try to
> explain
On Nov 16, 2013, at 3:32 AM, John Barton wrote:
> Could someone help me understand why two goals for parsing JS is a good thing?
Hm, it sounds like you've assumed a conclusion already. Let me try to explain
anyway.
Scripts are for synchronous loading and evaluation; modules are for
asynchrono
Could someone help me understand why two goals for parsing JS is a good
thing?
On Mon, Nov 11, 2013 at 3:30 PM, John Barton wrote:
> Just a user-experience report with traceur: the following code fails to
> compile in the repl.html and command line compiler:
> -
> import {WrapNewObjectTrans
Just a user-experience report with traceur: the following code fails to
compile in the repl.html and command line compiler:
-
import {WrapNewObjectTransformer} from './WrapNewObjectTransformer';
export function transcode(src, url) {
var file = new SourceFile(url, src);
var reporter = n
15 matches
Mail list logo
