Inspirations from EMCAScript 6

[Tom King]

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

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/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?

[Adam Cameron]

On Friday, 6 March 2015 21:42:42 UTC, Tom King wrote:

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

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let

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.

-- 

Adam

[Adam Cameron]

On Sunday, 8 March 2015 07:49:57 UTC, Adam Cameron wrote:

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.

-- 

Adam

[Jesse Shaffer]

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) ;)

https://groups.google.com/forum/m/#!topic/railo/oOLZfrrbcyI

[Jesse Shaffer]

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.

[Adam Cameron]

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) ;)

 https://groups.google.com/forum/m/#!topic/railo/oOLZfrrbcyI

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

[Adam Cameron]

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

[Jesse Shaffer]

I just raised this issue: https://bitbucket.org/lucee/lucee/issue/219/block-local-scoping

[Jesse Shaffer]

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.