Conditional Compilation: add to Gecko

[VK]

Taking into account many new features in JavaScript1.6 and
JavaScript1.7 which are syntactically incompatible with Javascript
versions run on other browsers: would it be reasonable to propose as
"new feature request" at bugzilla.mozilla.org the conditional
compilation mechanics. Obviously this mechanics has to be then fully
compatible with the existing one for IE:
http://msdn2.microsoft.com/en-us/lib...t1(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?

[VK]

On Dec 18, 5:08 pm, VK <[e-mail]:

Taking into account many new features in JavaScript1.6 and
JavaScript1.7 which are syntactically incompatible with Javascript
versions run on other browsers: would it be reasonable to propose as
"new feature request" at bugzilla.mozilla.org the conditional
compilation mechanics?

If anyone has an opinion on that and Bugzilla account she/he can also
comment at https://bugzilla.mozilla.org/show_bug.cgi?id=408835

In the latter case a possible "excited lexicon" of some clj posters
should be avoided so preserved for clj itself ;-)

[Randy Webb]

VK said the following on 12/18/2007 9:08 AM:

Taking into account many new features in JavaScript1.6 and
JavaScript1.7 which are syntactically incompatible with Javascript
versions run on other browsers: would it be reasonable to propose as
"new feature request" at bugzilla.mozilla.org the conditional
compilation mechanics.

No, it would be a stupid idea. It will put you back in the days of
language="javascript1.2".

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

On Dec 19, 2:54 am, Randy Webb <[e-mail]:

No, it would be a stupid idea. It will put you back in the days of
language="javascript1.2".

IMHO right the opposite, it would take us away from the old times with
separate files for separate situations. Though Brendan Eich seems to
think that "javascript1.2" way is still good enough and I'm of course
not in the position to enforce my opinion onto Gecko team: see
responses at
https://bugzilla.mozilla.org/show_bug.cgi?id=408835

[Randy Webb]

VK said the following on 12/19/2007 12:04 AM:

On Dec 19, 2:54 am, Randy Webb <[e-mail]:

>No, it would be a stupid idea. It will put you back in the days of
language="javascript1.2".

IMHO right the opposite, it would take us away from the old times with
separate files for separate situations. Though Brendan Eich seems to
think that "javascript1.2" way is still good enough and I'm of course
not in the position to enforce my opinion onto Gecko team: see
responses at
https://bugzilla.mozilla.org/show_bug.cgi?id=408835

That is not even close to what Brendan was talking about in that thread.
It is nice to see that people outside of c.l.j can't understand you either.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

VK said the following on 12/19/2007 12:04 AM:

On Dec 19, 2:54 am, Randy Webb <[e-mail]:

>No, it would be a stupid idea. It will put you back in the days of
language="javascript1.2".

IMHO right the opposite, it would take us away from the old times with
separate files for separate situations. Though Brendan Eich seems to
think that "javascript1.2" way is still good enough and I'm of course
not in the position to enforce my opinion onto Gecko team: see
responses at
https://bugzilla.mozilla.org/show_bug.cgi?id=408835

Just for kicks and giggles:

<quote cite="VK in URL above">
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.
</quote>

Do you ever stop and think about what you are writing before you write it?
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

On Dec 19, 8:41 am, Randy Webb <[e-mail]:

<quote cite="VK in URL above">
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.
</quote>

Do you ever stop and think about what you are writing before you write it?

Fine, rather than to be proven to be an idiot by Brendan Eich I prefer
to be proven to be an idiot by Randy Webb. As I guess the pleasure
should be mutual.

When server gets the request from client then it has two options: i)
choose the right script to send out of several or ii) to send single
script that will accommodate itself at runtime server-side. AFAIK the
second option is currently prevailing. This way I do not understand
the reasoning of using language or type attribute for script tag. And
if we heed runtime client-side accommodation then why do we need to
depend on unreliable feature detection that can be easily spoofed and
even if not then doesn't guarantee that this is _that_ method with
_that_ outcome?
After long time forgotten conditional compilation has been "re-
discovered" everyone just jumped on it as the only really reliable
detection method. So instead of
if (windows.ActiveXObject)
it is now /*@cc_on */ etc
because it is the only one bringing some trust to the developer. So
why the same thing which is great for one application is evil for
other? That would be the case if we had the situation of 1997/98
"whatever is not X - is Y" but we have not this situation as of now.

Just some idiotic thoughts of mine...

[VK]

On Dec 19, 11:08 am, VK <[e-mail]:

When server gets the request from client then it has two options: i)
choose the right script to send out of several or ii) to send single
script that will accommodate itself at runtime server-side.

.... will accommodate itself at runtime client-side

Damn it. However obvious the typo is, I hope it will not become the
main subject of the discussion.

[Randy Webb]

VK said the following on 12/19/2007 3:08 AM:

On Dec 19, 8:41 am, Randy Webb <[e-mail]:

><quote cite="VK in URL above">
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.
</quote>

Do you ever stop and think about what you are writing before you write it?

Fine, rather than to be proven to be an idiot by Brendan Eich I prefer
to be proven to be an idiot by Randy Webb. As I guess the pleasure
should be mutual.

Yippeeeeee, I get to be proven an idiot by VK. This should be
entertaining. Hold on to your britches. It's gonna be a blast.

When server gets the request from client then it has two options: i)
choose the right script to send out of several or ii) to send single
script that will accommodate itself at runtime client-side. AFAIK the
second option is currently prevailing.

I changed the text above to reflect your self-correction. The second
option prevails because it is the most reliable option. Hands down.

This way I do not understand the reasoning of using language or type
attribute for script tag.

Because some pedantic moron at the W3C decided it should be mandatory
when it is typically useless.

And if we heed runtime client-side accommodation then why do we need to
depend on unreliable feature detection that can be easily spoofed and
even if not then doesn't guarantee that this is _that_ method with
_that_ outcome?

You have that same problem with the first option. Anything the browser
tells the server is spoof-able. So, how is it any more reliable to let
the server decide what to send if what it is being told is 100% spoof-able?

After long time forgotten conditional compilation has been "re-
discovered" everyone just jumped on it as the only really reliable
detection method.

They did? I haven't seen 20 posts in the last two years that used it and
about half of those are my own posts. So I don't see where "everyone
just jumped on it".

So instead of
if (windows.ActiveXObject)
it is now /*@cc_on */ etc
because it is the only one bringing some trust to the developer.

Any developer that does that is ignorant at best.

So why the same thing which is great for one application is evil for
other?

I have never thought of conditional compilation great for anything. I
use it as a self-admitted crutch and am leaning heavily towards a
different test in the one place I use it.

That would be the case if we had the situation of 1997/98
"whatever is not X - is Y" but we have not this situation as of now.

And that is what you are advocating doing again? You want it so that you
can distinguish between IE, Gecko, and any others? That is right back
where you started in 1997. 10 years of evolution to get right back where
you started. That isn't a step forward, it is 100 steps backwards.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

On Dec 20, 1:58 am, Randy Webb <[e-mail]:

Fine, rather than to be proven to be an idiot by Brendan Eich I prefer
to be proven to be an idiot by Randy Webb. As I guess the pleasure
should be mutual.

Yippeeeeee, I get to be proven an idiot by VK. This should be
entertaining. Hold on to your britches. It's gonna be a blast.

I guess it is my problem in the Usenet. In my own company I am ideas
generator rather than end-developer though I was in the latter
position for many years. This way I have a person who can make a
decent coffee for me and a person who takes my hints on the fly to
make anything out of them - or to prove them to be a trash. While the
coffee is not a crucial problem if I'm left alone - I still can make
myself something caffeine-containing: the habit to express only the
most necessary from my point of view positions hits me often, as I
don't have the regular guy to explain "VK meant to say..."

Any way: "VK meant to say: it will be more pleasurable to be proved to
be an idiot by Randy Webb rather than by Brendan Eich: whatever
'pleasure' it could be as such. It also should be pleasurable to Randy
Webb to prove once again that VK is an idiot. This way the pleasure
should be mutual".
Ooh.. I'm glad I'm keeping that guy on the salary...

[Randy Webb]

VK said the following on 12/19/2007 6:43 PM:

<snip>

Ooh.. I'm glad I'm keeping that guy on the salary...

I know a lot of people that would be glad if you let him post to Usenet
for you.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/