Thanks Kevin. I'm going to challenge your list below, but I hope you don't
take it negatively. I want the case for the module system to be as strong
as possible.
On Sat, Jun 28, 2014 at 11:51 AM, Kevin Smith <zenpars...@gmail.com> wrote:
>
>>> Static checking of imports and exports has well-known advantages and
>>> would help the long-term viability of the language.
>>>
>>
>> Enumerating these specific advantages would inform this discussion.
>> These advantages are not well-known. Many developers have experienced the
>> disadvantages of complex systems of rules and thus favor simple solutions
>> over ones with theoretical advantages. Explaining the benefits concretely
>> would help them balance the well-known costs.
>>
>
> So pretty much everything in Javascript is dynamic, which is one reason
> why IDE support for Javascript has always lagged behind. You simply can't
> know what anything is until you actually run the program. Statically
> verifiable exports gives us the ability to inspect and analyze code without
> having to run it. There are two big benefits that this affords us:
>
> ## Early Errors and Warnings ##
>
> Let's say that you want to deprecate and remove an exported member from a
> module within a large JS code base. With static imports, the system will
> generate an error at compile time if something on the other side of that
> codebase is importing it.
>
It seems to me that the compiler can verify these two statements with equal
success:
import {foo} from './foo';
var foo = require('./foo.js').foo;
I agree that as a practical matter compilers may be more likely to
implement checks on the first form simply because it is standard. And I
agree that the language-defined module syntax will lead to better quality
tools simply because more developers have formal training in compiler
technology than have training in dynamic analysis. These are important
pragmatic issues.
Or am I wrong and these are not equivalent? Or there are examples which
show the issue more clearly?
> For exported function declarations that use default parameters to indicate
> optional parameters, we can generate build-time warnings when such an
> function is imported and called with too few arguments.
>
A good argument for default parameters.
>
> For exported classes, we have even more static information at our hands.
> Without having to run the program, we know the number of arguments for the
> constructor and we know the list of methods for class instances. We can
> generate warnings when we see an instance using a misspelled method name,
> for instance.
>
A good argument for standard rather than ad-hoc class class syntax.
>
> ## Computer Aided Coding ##
>
> The information used above to generate lint-like warnings can also be used
> to give the developer in-editor feedback. Reliable code-completion for
> imported function and class declarations becomes possible. Again, for
> exported classes we can also do code completion for instance methods.
>
> These advantages may not seem like a big deal now, but imagine writing JS
> in a large team five years from now. Do you want the power of static
> analysis at your team's fingertips, or do you want to be stuck with
> "anything goes so anything can break" CommonJS modules?
>
> Does that do it?
>
These are arguments for statically computable import module names -- so the
compiler can determine the imports without executing source code -- and for
top-level or hoisted (static) import statements -- so every import in a
module is a dependency of the module without runtime conditionals. I
believe that both of these limitations would be acceptable to almost all
developers interested in using modules.
Unfortunately I think we need more specific and detailed examples to
understand the advantages of the static form.
Thanks,
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
