Page 1 of 1

support for the 'const' keyword?

PostPosted: Sat Feb 19, 2011 1:55 pm
by ryanparrish
I have a few constants defined as globals that I use in my system that I make sure to treat very delicately when evaluating them, having one change because of a programing mistake would be detrimental to the system (as is the use case for most constants constructs).

I noticed rhino supports the const keyword, however if I try to use it in a global definition servoy becomes quite unhappy and sees it as a syntax error. Is the support already in Servoy and I'm perhaps not assigning it correctly?

Code: Select all
Ryan-Parrishs-MacBook-Pro:~ rparrish$ rhino
using CLASSPATH=/usr/local/bin/rhino/*:/usr/local/rhino1_7R2/*
Rhino 1.7 release 2 2009 03 22
js> const test_constant = 12345
js> test_constant
12345
js> test_constant = 54321
54321
js> test_constant
12345
js>


Of course the ECMAScript implementation of constants leaves a bit to be desired, I would much prefer it to throw an exception in the event something tries to re-assign the value, much like every other language that supports constants that I can think of right now, but we take what we can get I guess.

Re: support for the 'const' keyword?

PostPosted: Sat Feb 19, 2011 2:47 pm
by ROCLASI
Hi Ryan,

I support your request.
But for now you could simply make a variable into a function so the value is read-only.
Code: Select all
var test_constant = function(){return 12345}


Hope this helps.

Re: support for the 'const' keyword?

PostPosted: Sat Feb 19, 2011 2:51 pm
by ROCLASI
Err. Of course you can overwrite that function var. So never mind my suggestion.

Still +1 on the const keyword support.

Re: support for the 'const' keyword?

PostPosted: Mon Feb 21, 2011 11:22 am
by pbakker
The const keyword is a syntax extension by Mozilla, AFAIK no other JavaScript engines support it.

Only in the next version of the EcmaScript (== JavaScript) standard are they going to formalize it and define how it's to behave.

Paul

Re: support for the 'const' keyword?

PostPosted: Mon Feb 21, 2011 2:49 pm
by ryanparrish
According to this, https://developer.mozilla.org/en/JavaSc ... ents/const Safari and Opera's engines (I have trouble keeping up with whatever they are named ATM) have some support. But Mozilla has had support since 2000 (JavaScript 1.5), so since we are pretty much married to a Mozilla engine, why not utilize all of its bells and whistles? There's no reason to attempt cross browser compatibility for a non-browser application as far as i can see...?

Re: support for the 'const' keyword?

PostPosted: Mon Feb 21, 2011 3:21 pm
by pbakker
We stick to standards if we can.

As const is a syntactical addition (unlike Continuations for example), external tools might break, like the JSDoc plugin might break (as this one is based in part on Rhino as well, maybe it also supports const, I'm not sure, but you get the idea).

Also, if we would start supporting it now, you'd be relying on it's behavior, while that might change when the spec gets finalized and implemented.

Paul

Re: support for the 'const' keyword?

PostPosted: Fri Oct 25, 2013 6:13 pm
by deezzub
Now we have 2013 and Servoy 7.3, but not a global "const".

2013-10-25 18_05_54-global_scope_const_error.png
Global scope const error
2013-10-25 18_05_54-global_scope_const_error.png (15.47 KiB) Viewed 4979 times


Would be great to have it. ;)

Re: support for the 'const' keyword?

PostPosted: Sun Oct 27, 2013 3:01 pm
by jcompagner
will not happen because javacript/ecma spec doesn't support this.

Re: support for the 'const' keyword?

PostPosted: Mon Oct 28, 2013 9:32 am
by pbakker
A correction to what Johan wrote above: support for constants using th ekeyword is in the proposed spec for EcmaScript 6, which, according to their wiki, is due to be finalized this December.

When finalized, proper support still needs to be implemented by JavaScript engines, including the Rhino JavaScript engine used by Servoy, before we could expose it.

Note that the current constants support implemented in the Rhino engine is not compatible with the upcoming standard, hence our decision not to expose it.

Paul