4 ms·

> If it gets block scope [...] it has block scope since Javascript 1.7 (which is of course only supported on the client side by Firefox (FF 2) and I think Webk

by jsrn 18y ago

> If it gets block scope [...] it has block scope since Javascript 1.7 (which is of course only supported on the client side by Firefox (FF 2) and I think Webkit) and on the server side it's supported in Rhino 1.7R1 and of course Spidermonkey. block scoping overview and examples (search for let statements, let expressions, let definitions): http://developer.mozilla.org/en/New_in_JavaScript_1.7 http://developer.mozilla.org/en/New_in_JavaScript_1.7

SwellJoe 18y ago
Sweet! And since you get to pick your implementation for server-side work, you don't have to remain in the IE ghetto. But, obviously, I haven't been following JavaScript all that closely. I guess they had to use a different keyword instead of var (much like Perl introduced my because local already meant something strange in Perl 4, and for sort of the same purpose...though my became the new right way to declare variables anywhere, since the goal is always to get smaller scope for variables, and it doesn't look like that's the right idea with let). JavaScript still doesn't have namespaces or a package/module concept, though (right?), so it seems like there'd still be some pain points in building large modular software. Of course, it's a pretty flexible language, and I've seen some interesting usage of closures to replicate namespaces and packages, so I guess standardizing on a library that provides those facilities is all that's really needed.
- jsrn 18y ago
  > though my became the new right way to declare variables > anywhere, since the goal is always to get smaller > scope for variables, and it doesn't look like that's the > right idea with let well, it's a bit different than local/my in Perl: variables declared local are dynamically scoped, variables declared my lexically (with block granularity). Given the choice, most of the time the lexically scoped (my) variant wins hands down. With Javascript, it's a choice between lexically scoped and lexically scoped - the only difference is the granularity: var has function level granularity, let has block level granularity. So in many cases it doesn't really matter, I think. At least the benefit of let over var isn't nearly as strong as it was in Perl of my over local. Having said that, there is no particular reason why you shouldn't make let your variable declaration keyword of choice.
- JulianMorrison 18y ago
  Packages, the concept, make me say "hmm". Why do you need a separate sort of namespacing entity than objects?
  - procrastitron 18y ago
    A strictly less powerful namespacing entity at that... If you used objects for namespaces, then you can create new ones at runtime, pass custom namespaces to different modules, and a lot of other nifty things I haven't even thought of yet.
  - SwellJoe 18y ago
    Why do you need a separate sort of namespacing entity than objects? I probably don't. I'm just another Perl hacker who thinks it's nice being able to use any programming concept anyone ever thought of all in one language. It's a flaw.
    - bkudria 18y ago
      Upmod for honesty.

by jsrn 18y ago

SwellJoe 18y ago

Sweet! And since you get to pick your implementation for server-side work, you don't have to remain in the IE ghetto. But, obviously, I haven't been following JavaScript all that closely. I guess they had to use a different keyword instead of var (much like Perl introduced my because local already meant something strange in Perl 4, and for sort of the same purpose...though my became the new right way to declare variables anywhere, since the goal is always to get smaller scope for variables, and it doesn't look like that's the right idea with let). JavaScript still doesn't have namespaces or a package/module concept, though (right?), so it seems like there'd still be some pain points in building large modular software. Of course, it's a pretty flexible language, and I've seen some interesting usage of closures to replicate namespaces and packages, so I guess standardizing on a library that provides those facilities is all that's really needed.

jsrn 18y ago
> though my became the new right way to declare variables > anywhere, since the goal is always to get smaller > scope for variables, and it doesn't look like that's the > right idea with let well, it's a bit different than local/my in Perl: variables declared local are dynamically scoped, variables declared my lexically (with block granularity). Given the choice, most of the time the lexically scoped (my) variant wins hands down. With Javascript, it's a choice between lexically scoped and lexically scoped - the only difference is the granularity: var has function level granularity, let has block level granularity. So in many cases it doesn't really matter, I think. At least the benefit of let over var isn't nearly as strong as it was in Perl of my over local. Having said that, there is no particular reason why you shouldn't make let your variable declaration keyword of choice.
JulianMorrison 18y ago
Packages, the concept, make me say "hmm". Why do you need a separate sort of namespacing entity than objects?
- procrastitron 18y ago
  A strictly less powerful namespacing entity at that... If you used objects for namespaces, then you can create new ones at runtime, pass custom namespaces to different modules, and a lot of other nifty things I haven't even thought of yet.
- SwellJoe 18y ago
  Why do you need a separate sort of namespacing entity than objects? I probably don't. I'm just another Perl hacker who thinks it's nice being able to use any programming concept anyone ever thought of all in one language. It's a flaw.
  - bkudria 18y ago
    Upmod for honesty.