Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

const and/or var #139

Closed
satyr opened this issue Jun 20, 2012 · 11 comments
Closed

const and/or var #139

satyr opened this issue Jun 20, 2012 · 11 comments

Comments

@satyr
Copy link
Owner

satyr commented Jun 20, 2012

const

Performs a series of assignments and flags the variables as read-only.

const a = 0, b = 1
...
a = 2  # compile error

var

Avoids awakward a = b = void.

var a, b
@paulmillr
Copy link

const is a pretty awesome idea if it'll be compile time. 👍

@michaelficarra
Copy link
Contributor

Yes, assignment is horrible. But you won't be able to enforce this statically when the constants are members of the global scope. Is that an acceptable inconsistency?

@satyr
Copy link
Owner Author

satyr commented Jun 20, 2012

when the constants are members of the global scope

Global variables are read-only already:

$ coco -e '++Math'
SyntaxError: increment of undeclared variable "Math" on line 1

@michaelficarra
Copy link
Contributor

$ node
> var a = 0
undefined
> this.a
0
> this.a = 1
1
> a
1
> 

You can't statically catch those assignments.

@satyr
Copy link
Owner Author

satyr commented Jun 20, 2012

You can't statically catch those assignments.

Don't have to.

  • this.a is not a variable.
  • Coco can't declare global variables (or pretends so in case of --bare).

@michaelficarra
Copy link
Contributor

Exactly. When --bare is used, top-level "consts" are re-assignable through a reference to the global object. Are you willing to ignore that case? If I saw that a language had a "constant" feature, I would hope that it could guarantee that the value would never change, regardless of environmental factors like what flags were used when the program was compiled.

@satyr
Copy link
Owner Author

satyr commented Jun 20, 2012

Are you willing to ignore that case?

Yes. --bare is for cases where the IIFE wrapper is redundant (like node modules) and never for creating globals.

@michaelficarra
Copy link
Contributor

That's reasonable.

@satyr satyr closed this as completed in 3564f93 Jun 21, 2012
@paulmillr
Copy link

@michaelficarra would you consider this (at least const) for coffee-redux?

@michaelficarra
Copy link
Contributor

@paulmillr: Absolutely not. The goal of CoffeeScriptRedux is to be feature-compatible with CoffeeScript, with no feature additions besides those listed on the kickstarter page. Once it reaches that state, I plan to fork it and add cool features (like const) that I've enumerated at coffee-of-my-dreams, many of which are already available in LiveScript.

@paulmillr
Copy link

ah, that's even cooler. then it will be truly drop-in replace. nice to hear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants