'var' and 'const' keywords

[Patient Guy]

Has anyone found it possible---that is, come up with a "trick"----to
specify IN THE SAME SCOPE 'const' for non-reassignable variables, with the
use of 'var' as a fallback should the interpreter respond with an error
upon seeing 'const'?

In pseudo-code:

try_this {

const SOME_CONSTANT = 0,
ANOTHER_CONSTANT = 1;

} or_try_this {

// re-assignable definitions despite not being wanted

var SOME_CONSTANT = 0,
ANOTHER_CONSTANT = 1;

}

Note that a try/catch block will fail presumably because they are in the
same scope, of which there are only two scopes in
ECMAScript/Javascript/JScript, as near as I can tell.

If that is asking for the existence of a logical contradiction, then what
other means is there to obtain this?
PG

[RobG]

Patient Guy wrote:

Has anyone found it possible---that is, come up with a "trick"----to
specify IN THE SAME SCOPE 'const' for non-reassignable variables, with the
use of 'var' as a fallback should the interpreter respond with an error
upon seeing 'const'?

In pseudo-code:

try_this {

const SOME_CONSTANT = 0,
ANOTHER_CONSTANT = 1;

const is a future reserved word but is not a key word nor does it have
any special meaning in ECMAScript Ed 3.

It has been suggested for inclusion in the next version of ECMAScript
and JavaScript 2.0. There are some interesting links here:

<URL: http://www.mozilla.org/js/language/ >
If you want to create a variable that can't be modified, create it as
a private member of an object and that also has a privileged method
that reads it (but can't write to it):

<URL: http://www.crockford.com/javascript/private.html >
Set its value when you create the object. Not foolproof, but if you
want something more provide a scenario.
[...]
--
Rob

[Martin Honnen]

RobG wrote:

const is a future reserved word but is not a key word nor does it have
any special meaning in ECMAScript Ed 3.

It has been suggested for inclusion in the next version of ECMAScript
and JavaScript 2.0.

It is correct that in ECMAScript edition 3 const is only future
reserved. However Netscape's respectively now Mozilla's JavaScript
implementation for JavaScript 1.5 and later already supports const e.g.

const GOD = 'Kibo';
alert(GOD)

It is obviously not possible to use that on the web as most other
implementations will give you a syntax error but for Mozilla specific
scripting (XUL, extensions) it can be used and is used.

--

Martin Honnen
http://JavaScript.FAQTs.com/

[VK]

Patient Guy wrote:

Has anyone found it possible---that is, come up with a "trick"----to
specify IN THE SAME SCOPE 'const' for non-reassignable variables, with the
use of 'var' as a fallback should the interpreter respond with an error
upon seeing 'const'?

This is not the problem of the *execution* - it is the problem of
*pre-processing* when the source code is being parsed and broken on
tokens.

While you have plenty of control during the execution like
if(document.someMethod) etc. there is nothing you can do with
pre-processing *from within the script itself* : an absolute shiny
none. I'm saying it in case if you're currently trying to find some
"hack".
An absolute shiny none because pre-processing errors will happen
*before* the execution - thus before your script will become.

The only possibility (as in all other languages) is to use
pre-processor commands. Unfortunately up do date IE is the only browser
with an open interface pre-processor. All others still prefer to sit on
the cloud.

<script type="text/javascript">
/*@cc_on
@if (@_jscript_version >= 7)
/* JScript.Net with const support */
const foo = 'bar';
@elif (@_jscript)
/* some JScript but not JScript.Net */
var foo = 'bar';
@else @*/
/* Non-IE browser: act on your own risk */
// ?
/*@end @*/
</script>

[Thomas 'PointedEars' Lahn]

VK wrote:

Patient Guy wrote:

Has anyone found it possible---that is, come up with a "trick"----to
specify IN THE SAME SCOPE 'const' for non-reassignable variables, with
the use of 'var' as a fallback should the interpreter respond with an
error upon seeing 'const'?
This is not the problem of the *execution* -

(That would be the interpretation of the compiled byte-code.)
it is the problem of *pre-processing* when the source code is being
parsed and broken on tokens.

That is compilation of the source code. JS/ECMAScript != PHP.
PointedEars

[VK]

Thomas 'PointedEars' Lahn wrote:
<snip>

(That would be the interpretation of the compiled byte-code.) <snip> That is compilation of the source code. JS/ECMAScript != PHP.

Right.

Also please note that one should avoid nested comments as it can hit
you. I used internal comments in the posted code only to... uhm...
comment the branches. On a real run keep your comments with you or
outside of the @cc block.