If we can agree that some <script> element variant imports * from
"@std" implicitly as a standard prelude,
For backward compatibility and even convenience, it's necessary to have
this implicit standard module.
Assuming this is true, is there even a point at defining a standard module?
When would one use it as a module instead of how using primordial as it
is done today?
I'm also worried that a standard built-in module is something developer
won't have control on. Specifically, how can they polyfill it if they
need to?
Le 14/04/2012 05:20, Brendan Eich a écrit :
> (...)
>
> If we can agree that some <script> element variant imports * from
> "@std" implicitly as a standard prelude,
For backward compatibility and even convenience, it's necessary to have
this implicit standard module.
Assuming this is true, is there even a point at defining a standard module?
When would one use it as a module instead of how using primordial as it
is done today?
I'm also worried that a standard built-in module is something developer
won't have control on. Specifically, how can they polyfill it if they
need to?
David
Le 14/04/2012 05:20, Brendan Eich a écrit :
For backward compatibility and even convenience, it's necessary to have this implicit standard module. Assuming this is true, is there even a point at defining a standard module? When would one use it as a module instead of how using primordial as it is done today?
I'm also worried that a standard built-in module is something developer won't have control on. Specifically, how can they polyfill it if they need to?