Inspirations from EMCAScript 6

I was at jQueryUK today, and one of the things coming up in EMCAScript 6 is
the concept of “let”

One of the interesting things I found was this allows scoping like var,
but within code blocks, like “if” statements.

i.e, in pseudocode:

function foo(){
var a = 5;
var b = 10;

if (a === 5) {
let a = 4; // The scope is inside the if-block
var b = 1; // The scope is inside the function

writeDump(a); // 4
writeDump(b); // 1
}

writeDump(a); // 5
writeDump(b); // 1
}

To me, this has some interesting advantages, especially inside loops and
conditional statement blocks (think counters, or indeed any variable you
wish to remain private to that piece of code etc).
I’m assuming this isn’t currently possibly in lucee.

Good thing or not? Thoughts?

I had brought this up on the railo forums. Interestingly enough Adam, you seem to have changed your mind from last time (concerning the admin option that is) :wink:

Redirecting to Google Groups

Full disclosure: I prefer adding the let keyword. It may not yet be prevalent in JS, but it will. I would rather have this as a new concept and keyword instead of having to add documentation that “this particular app” has to have this such and such admin config, oh, and thats why its codebase works slightly different from the others.

I was at jQueryUK today, and one of the things coming up in EMCAScript 6
is the concept of “let”

let - JavaScript | MDN

One of the interesting things I found was this allows scoping like var,
but within code blocks, like “if” statements.

Probably closer to home for CFML is the fact Java does this:
http://docs.oracle.com/javase/specs/jls/se6/html/statements.html#263461

It doesn’t need a special statement, it’s just the way it works. The
parallel in CFML would be to have the var keyword act the way you
prescribe. There’d be backwards compat issues, so it’d perhaps need to have
some sort of compiler option to vary the behaviour.

I thought I’d raised this in the past, but can find no evidence of it (on
Railo or ColdFusion).

I’d vote for it if it was raised.On Friday, 6 March 2015 21:42:42 UTC, Tom King wrote:


Adam

Full disclosure: I prefer adding the let keyword. It may not yet be
prevalent in JS, but it will. I would rather have this as a new concept
and keyword instead of having to add documentation that “this particular
app” has to have this such and such admin config, oh, and thats why its
codebase works slightly different from the others.

Yup: very good point. If it was to be added for CFML files, I definitely
agree. And, extending from that, .lucee files should take the same approach
if both were gonna do it.

However I have cooled (to the point of freezing) about the idea of Lucee’s
CFML diverging any further from Adobe’s, so would rather this only
happening for the Lucee dialect. If that is still gonna be a thing.

Have you raised a ticket for this?On Sunday, 8 March 2015 12:46:52 UTC, Jesse Shaffer wrote:


Adam

There’d be backwards compat issues, so it’d perhaps need to have some sort
of compiler option to vary the behaviour.

I dunno if this notion of having a new special Lucee dialect actually ended
up being “a thing”… but it would perhaps be the sort of thing to
implement as the default behaviour there, and just leave the CFML
implementation as-is.On Sunday, 8 March 2015 07:49:57 UTC, Adam Cameron wrote:


Adam

I had brought this up on the railo forums. Interestingly enough Adam, you
seem to have changed your mind from last time (concerning the admin option
that is) :wink:

Redirecting to Google Groups

I don’t believe I mentioned an admin option. I think all the admin
(shouldn’t have to do this stuff via a UI) and Application.cfc (code
compilation should not be controlled @ runtime) options
Railo^h^h^h^h^hLucee has are a bit shit. I was thinking more a compiler
config file or [something… just neither of the two existing approaches].

Or, as I went on to suggest… don’t do it for CFML at all, just do it for
.lucee files.

That said… [over to your other response now]…On Sunday, 8 March 2015 12:40:10 UTC, Jesse Shaffer wrote:


Adam

You did not mention one, however, you did mention

For my own part, all these admin settings which make code behave

differently is a bit crap, and should only ever be used to control
compatibility levels with CF, not to control Railo-specific functionality.
But that’s verging on a digression of its own.

Which, the phrase immediately following is what you may be using as
justification for allowing an admin option in this case. However, I see
block-local scoping as a complimentary feature that could be implemented
with zero admin configs necessary by borrowing the “let” keyword. It
doesn’t need to be back-ported to legacy CFML dialect, but it also doesn’t
need to introduce a breaking change that developers need to account for in
transitioning to a new dialect.On Sunday, March 8, 2015 at 9:13:58 AM UTC-5, Adam Cameron wrote:

On Sunday, 8 March 2015 12:40:10 UTC, Jesse Shaffer wrote:

I had brought this up on the railo forums. Interestingly enough Adam, you
seem to have changed your mind from last time (concerning the admin option
that is) :wink:

Redirecting to Google Groups

I don’t believe I mentioned an admin option. I think all the admin
(shouldn’t have to do this stuff via a UI) and Application.cfc (code
compilation should not be controlled @ runtime) options
Railo^h^h^h^h^hLucee has are a bit shit. I was thinking more a compiler
config file or [something… just neither of the two existing approaches].

Or, as I went on to suggest… don’t do it for CFML at all, just do it for
.lucee files.

That said… [over to your other response now]…


Adam

I just raised this
issue: Log in with Atlassian account Sunday, March 8, 2015 at 9:16:38 AM UTC-5, Adam Cameron wrote:

On Sunday, 8 March 2015 12:46:52 UTC, Jesse Shaffer wrote:

Full disclosure: I prefer adding the let keyword. It may not yet be
prevalent in JS, but it will. I would rather have this as a new concept
and keyword instead of having to add documentation that “this particular
app” has to have this such and such admin config, oh, and thats why its
codebase works slightly different from the others.

Yup: very good point. If it was to be added for CFML files, I definitely
agree. And, extending from that, .lucee files should take the same approach
if both were gonna do it.

However I have cooled (to the point of freezing) about the idea of Lucee’s
CFML diverging any further from Adobe’s, so would rather this only
happening for the Lucee dialect. If that is still gonna be a thing.

Have you raised a ticket for this?


Adam