408835 - Add pre-processor (conditional compilation) to SpiderMonkey

Status: VERIFIED WONTFIX

(Core :: JavaScript Engine, enhancement)

Description

[VK]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Gecko/20071127 Firefox/2.0.0.11

Taking into account many new features in JavaScript1.6 and JavaScript1.7 which are syntactically incompatible with Javascript versions run on other browsers and with each other (new keywords): would it be reasonable to propose the conditional compilation mechanics? Such mechanics should be then fully compatible with the existing one for IE: http://msdn2.microsoft.com/en-us/library/7kx09ct1(VS.71).aspx and further links.

JScript sample:

<script>
/*@cc_on @*/
/*@if (@_jscript_version < 5.5)
 window.alert('JScript below 5.5');
  @elif (@_jscript_version >= 5.5)
 window.alert('JScript 5.5 or higher');
@else @*/
 window.alert('Not a JScript parser');
/*@end @*/
</script>

For the seamless accommodation it is needed to add to the list of conditional compilation variables extra two:

@_javascript
Always returns true for Gecko platforms.
Respectively @_jscript always returns false for Gecko platforms.

@_javascript_version with possible values 1.5, 1.6, 1.7, (1.8, ..)

IMO it is the only way to have any use out of extra features in a cross-browser way: leaving out different hacks with dynamic "<script>" write and separate .js files for different browsers. 

Any opinions on that?

Reproducible: Always

Comment 1

[Jeff Walden [:Waldo]]

Strangely I don't see any prior reports of this, so it doesn't look like a dup.

Conditional compilation encouraages engine-specific coding practices which are actively antithetical to the platform neutrality of the web (regardless that you can use it to provide fallback behavior -- you still have to make the effort to provide that fallback for "correct" behavior), so I don't see this passing muster as a good thing for the web.  As you note, compatibility can be an issue in certain cases.  In those cases Mozilla has a history of supporting backwards-incompatible changes through a MIME-type switch, wherein you specify a different type attribute on the script element to get different compilation semantics.  I don't see a need for a second mechanism which promotes platform splintering, and I don't see this changing; I recommend WONTFIX.

By the way, you really want hygienic macros rather than a preprocessor; preprocessing actively interferes with automated mechanisms for modifying code (witness the success of Java refactoring tools and the near-absence of anything similar for C++).  JavaScript is likely to pick up a macro mechanism, but that's several years out at the earliest.

Comment 2

[Brian Crowder]

Couldn't agree with Waldo more.

Comment 3

[Brendan Eich [:brendan]]

One more point: authors coding for downrev browsers do not want to write code twice, or 1.x times (where the 1 is the common downrev JS and the .x fraction is the part of that 1 rewritten to use the uprev JS features if supported). They tend to stick with the least common denominator revision of JS until the new revision is widespread, or use server-side translation to downrev from uprev, and ship the translated code to downrev browsers.

/be

Comment 4

[VK]

(In reply to comment #3)
> One more point: authors coding for downrev browsers do not want to write code
> twice, or 1.x times.

Very true.

> They tend to stick with the least common denominator revision of JS until the
> new revision is widespread, or use server-side translation to downrev from
> uprev, and ship the translated code to downrev browsers.

Very true again: so the proposal was to be able to shift the logic - which is in use anyway - from server side to client side without further need of unreliable browser sniffing on the server.

But if big buys are saying WONTFIX then so shall be it I guess.
Humbly remain on my own opinion though.

Comment 5

[Brendan Eich [:brendan]]

(In reply to comment #4)
> (In reply to comment #3)
> > One more point: authors coding for downrev browsers do not want to write code
> > twice, or 1.x times.
> 
> Very true.

Ok, so no writing it twice, or even 1.x times for non-trivial .x fraction.

I hope my point about automated code translation -- source-to-source compiling of JS2 to JS1 -- was clear. It may not have been, from the below exchange:

> > They tend to stick with the least common denominator revision of JS until the
> > new revision is widespread, or use server-side translation to downrev from
> > uprev, and ship the translated code to downrev browsers.
> 
> Very true again: so the proposal was to be able to shift the logic - which is
> in use anyway - from server side to client side without further need of
> unreliable browser sniffing on the server.

I do not understand: there's no shift of automatic translator from server to client side if this bug is fixed. Instead, authors have to use @if, etc. to "write things twice" at the limit, or 1.x times.

Browser sniffing is not unreliable if <script type=> is used per RFC 4329.

> But if big buys are saying WONTFIX then so shall be it I guess.
> Humbly remain on my own opinion though.

If I understood your opinion better, or you mine, we might come to agreement. So even though this is WONTFIX I am writing back to try to clarify what I wrote. Thanks,

/be