-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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 |
@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:
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).
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. |
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:
or
or
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.
The text was updated successfully, but these errors were encountered: