The double parse option is missing
mikesherov opened this issue · comments
Even though it's been rejected, it's missing from the list of possible options.
You mean [3] - the content sniffing proposal?
Thanks for putting this repo together!
Content sniffing isn't actually what's happening. Double parse is not fuzzy, per se. It's more that if you happen to have a module that doesn't use the module syntax, it'll be detected as a script, which is only a very minor edge-Casey problem.
it's been rejected more that it imposes a permanent performance penalty on using modules because they'd always need to be double parsed.
To that effect, I think content-sniffing should be renamed and the reasoning updated.
@mikesherov It is called Content Sniffing by Bradley Meck.
How about adding a "a.k.a Double Parsing", or something like that?
Also in the wiki entry Bradley lists
Hard to determine file mode for large files if they barely use a feature that causes a mode switch. (cause of rejection)
and
Ambiguity causes potential implicit semantic changes (cause of rejection)
Do you have a reference for the performance being the primary reason? I would like to link to it!
Hard to determine file mode for large files if they barely use a feature that causes a mode switch. (cause of rejection)
If we're doing actual double parse, this is just not true. That's why I think content sniffing is different from double parse.
Let me find performance reason in the "big thread".
Ambiguity causes potential implicit semantic changes (cause of rejection)
This is true though only in the case of a module that doesn't use module syntax at all. For the 99% case of modules that use module syntax, there is 0% ambiguity.
I think @bmeck was generalizing content-sniffing because a few different versions of it were being thrown around, but double-parsing is a distinct option. I'm on mobile so GH won't show me the whole thread but double parsing is mentioned a lot of times, and was referred to as pricey.
@mikesherov as it stands there is ambiguity, unless spec changes to remove that ambiguity parsing approach is not viable or even in consideration.
@bmeck please confirm that the ambiguity is as I stated though: when you have a module that doesn't use module syntax.
Please note that I'm not advocating this approach, I'm trying to correctly define its edge cases and drawbacks.
@mikesherov correct, side effect only modules are the ambiguity.
Added pr #14 that should fix this. A +1 would be mighty welcome.