Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why not indicate that a module is non-executable with a simpler or shorthand syntax? #90

Open
CxRes opened this issue Aug 1, 2020 · 2 comments

Comments

@CxRes
Copy link

CxRes commented Aug 1, 2020

Forgive me if this is a naive question: Why not just indicate that a module is a non-executable and use mime-type to determine format. Something maybe like:

import$ foo from 'foo.json'   // import$ as a new keyword

or

import foo from 'foo.json'!    // ! as the non-executable operator

or

import foo as 'foo.json'       // 'as' being a new keyword for use with import

This would work for a vast majority of cases where one uses a IANA registered media type (or perhaps even one derived from them subject to community consensus). The browser/engine can maintain a mapping or query the media type.

Consider another contrived scenario to illustrate the loss of flexibility: Say in the future, browsers had YAML and JSON parsers built in to the browser. An assertion to JSON would lock in a developer and if the module provider changed over to YAML this would lead to an error, even-though the parsed data might be the same.

I am not challenging the proposal itself, since I can see legitimate reasons to assert a format, mime-type, hashes etc. But why force a developer to add this extra code when a single token might do the job more often than not, leaving the code more readable and a few bytes lighter.

@xtuc
Copy link
Member

xtuc commented Aug 8, 2020

I don't think using a symbol is very clear, we currently have a syntax that makes it explict and easy to understand. For instance this case nodejs/modules#427 (comment).

Edit: Also here's a comment about it nodejs/modules#427 (comment).

The as syntax was proposed before but we decided to use a more generic approach, see #12.

@CxRes
Copy link
Author

CxRes commented Aug 9, 2020

@xtuc I am not arguing the explicit nature of the current proposal, neither am I arguing the ease of understanding. As I said above the explicit syntax is needed. However, it just appears to me that in an overwhelmingly large number of cases all a developer would want to indicate is that the thing being imported is not code, please don't try to run it - such a verbose syntax seems like an overkill in those situations and could do with a shorthand! My suggestions are merely the simplest proposals I could think of, better suggestions are of course welcome.

To your specific points:

For instance this case nodejs/modules#427 (comment).

Edit: Also here's a comment about it nodejs/modules#427 (comment).

I am not sure I understand the relevance of the linked comments. The first linked comment asks for an implicit determination of whether the import is executable which would be unclear and a security risk (as explained in the second linked comment). I am asking for explicit shorthand syntax to specify excitability (which mitigates the security risk) only after which mime-type determination would kick in (say a code js or wasm would be executed once marked executable and data whether yaml or json would never be executed once marked as non-executable).

The as syntax was proposed before but we decided to use a more generic approach, see #12.

I am sorry but I reject this contention! My "as" syntax suggestion is different from the one proposed in #12.

Also, Javascript already has a tradition of shorthand syntax. People get used to them, even like them, even if it seems unclear initially. I believe one should strive in a computer language (like we do in spoken language) to balance explicitness and simplicity. And I believe this is the best time to make this determination, before the syntax is finalized, rather than creating yet another proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants