Nick Husher wrote:
>> We could always just replace block open and close.
>>
>> block open with:
>> (function() {
>>
>> block close with:
>> }());
>>
>> would look like this:
>> if (something) (function() {
>> alert('it's ugly-time');
>> }());
>>
>> Unfortunately, javascript's function literal isn't as awesome as its
>> object literal.
>
> Yeah, that's what I meant by 'creating a new function'. In general,
> unless you're serious about data encapsulation, you'll only rarely need
> to do such a thing. It's also possible to be overzealous about creating
> anonymous function blocks: every function block carries with it a lot of
> complex operating context information that can have a performance impact
> (dynamically creating 1000 new closures with unique scopes available to
> them will cause slower browsers and slower machines to die cruelly).
>
> Were I teaching someone about Javascript in an academic environment, I
> would probably spend a lot longer on scope peculiarities with Javascript
> than I would with any other language. In one sense, it's more intuitive
> because there's no "masking" of more-global variables*, but it's a lot
> more confusing because functions are lexically scoped rather than
> dynamically scoped**.
>
> If I remember correctly, there was a proposal in Javascript 4 (ECMA6)
> that introduced a simple syntactical way to define a new context without
> creating a new function. I'm fairly sure it was just sugar for the code
> you wrote above, but it would make such code far more readable.
> Unfortunately, JS4 is dead for the time being. Most work on JS these
> days is in performance enhancements and feature extensions (see canvas,
> offline storage, etc) and there's a legitimate argument that any
> syntactic changes to JS will "break the web," an eventuality which has
> become intolerable as the web has matured.
IE already broke the web. Just incorporating a version statement would
be nice. I think most of the work you're describing refers to javascript
bindings more than it does javascript. For instance, DOM bindings.
>
> I'm going to guess that Jacob knows the following, so this is aimed more
> at the casual reader interested in learning about Javascript:
>
> * In C-like languages (C++, Java, etc) we can observe the following
> behavior. It's unintuitive to assign 10 to an already-existing variable
> and have it "mask" it rather than perform an actual assignment. Removing
> the "int" changes the behavior in a subtle but very important way. Using
> this property of the language is really powerful, but can lead to logic
> errors pretty quickly if you aren't careful.
>
> In javascript, we can write the equivalent and observe the difference.
> Assignments that take place within blocks (even if you attempt to
> redefine the variable) affect variables of the same name outside the block.
>
> // C-like language:
> int i = 5;
> if(1==1) {
> int i = 10;
> printf("%d\n", i); // prints "10"
> }
> printf("%d\n", i); // prints "5"
>
> // Javascript
> var i = 5;
> if(true) {
> var i = 10;
> console.log(i); // prints "10"
> }
> console.log(i); // prints "10"
>
>
> ** Lexical scoping is probably one of the trickiest aspects of
> Javascript that took me a long time to really internalize and use
> properly. It allows for the creation of closures, which are one way to
> do data hiding and, with Javascript's built-in scope binding functions,
> allow you to bend a function's scope to operate in many contexts. A
> basic example:
>
> var push, pop;
> (function() {
> var array = [];
> push = function(el) { array.push(el); };
> pop = function() { return array.pop(); };
> }());
> push("STRING");
>
> alert(pop()); // alerts "STRING"
> alert(array) // alerts "undefined";
>
>
Then there's Doug Crockford's "Javascript: The Good Parts" which is a
good read if you're interested in JS. The author is stylistically
strict, and in a my javascript coding style is the only right javascript
coding style kind of way.
|