Learning Advanced JavaScript
ejohn.org
ejohn.org
You can find more information about it here: http://ejohn.org/blog/adv-javascript-and-processingjs/
Most of this tutorial is taken from my upcoming book 'Secrets of the JavaScript Ninja' which can be found here: http://jsninja.com/
I don't think this was explicitly stated on the slides but you can double click the code slides and you'll be able to edit and re-run them. I tossed this tutorial up after the talk and haven't really had a chance to improve upon it.
Sort of related: Remy Sharp built http://jsbin.com/ which is based off of the construction of this tutorial (using the run-and-show style together with double-click-to-edit).
I could see many textbooks/subjects maths, physics, anything that fits the pattern "look at this" -> "what do you think will happen" -> "this! is what happens and why".
Nevertheless, they are fantastic. If anyone has links to similar presentations for other languages, I'd love to take a look.
http://ejohn.org/blog/adv-javascript-and-processingjs/
He also has it as a download: http://ejohn.org/files/learn.zip
Definitely going to look at his books now...
Oh his work here looks good too: http://jspro.org/code/
This is only true for properties created as new properties on the existing prototype (Ninja.prototype.swingSword = ...). It is not true if you assign a new object to the prototype (Ninja.prototype = { 'swingSword' : ...}).
The existing objects will only see new properties added to the object which was constructor's prototype at their creation time.
Which is what #67 says.
It is not true if you assign a new object to the prototype
Which is a completely different thing.
Nope, it says exactly what I quoted ("prototyped properties"). It also provides an example that happens to be of the later kind (properties set on existing prototype.)
"It is not true if you assign a new object to the prototype
Which is a completely different thing."
Completely different from everything that falls under "prototyped properties"? I disagree.
All in all, my point is that if you don't know exactly how it works then there is a chance you might be misled by this #67. I am not arguing that it is "wrong".
If you change an object's prototype, that object is no longer "of the same constructor". "Ninja.prototype = { 'swingSword' : ...}" is, in fact, a completely different, far more dramatic action than "Ninja.prototype.swingSword = ..." You shouldn't at all have the expectation that the two are anything alike.
It's rather "expanded using knowledge about Javascript object model plus subjective opinion about JS being retarded" than "losslesly translated".
Given that said knowledge is the knowledge that the slides are meant to convey, we have some circular reasoning here.
Given that you were critiquing #67 as though you thought you already understood the information, I felt it was fair game to call you out for being wrong about it. Apologies.
The 'prototype' property on the constructor indicates what will be assigned as the prototype of instances created in the future with that constructor. The property can be changed, but that does not affect existing instances created with the constuctor. It would probably be less confusing if the 'prototype' property was called 'assignPrototype' or something like that.
The prototype (ie. __proto__ property) of an instance cannot be changed according to the standards (although some non-standard implementations allow that). That is, it cannot be changed to point to a different object, but the prototype object itself is mutable, and when you change it it will affect all instances sharing the prototype.
It is not uncommon to think of constructors as equivalent to classes, however technically prototypes and constructors are independent. You can create instances with different prototypes from the same constructor, and you can create instances with the same prototype from different constructors.
This is exactly the kind of thing that makes Javascript so disappointing. ninja is an object, that has a slot yell. yell refers to a function/closure. Samurai is a _new_ object, with a _new_ slot, that _independently_ refers to the same function that yell in ninja refers to.
And yet, when ninja is deleted/collected the function yell disappears. This is insanity. In javascript
function(n) { blah }
And yet it does.
Can anybody think of a justification for this absurd behavior?
What goes wrong is this: when it tries to call itself recurively by using ninja.yell, ninja already refers to null. That's when it fails.
The moral of this slide is "If you want a function to call itself, better give it a name and refer to it by the name instead of relying on bindings that are outside the scope of the function." This has a followup in the next slide, where exactly this happens.
Or just use the arguments.callee property which allows you to call the function from itself without worrying about names.
edit: oops, just seen that's on a later slide.
var ninja = {
yell: function () {
var yellLocal = function(n) {
return n > 0 ? yellLocal(n-1) + "a" : "hiy";
}
return yellLocal;
}()
}Firefox 3.5.3, Firebug 1.4.2
function largest(){ return Math.max.apply( Math, arguments ); } <-- why is it necessary to run this function in the context of "Math". I don't get this...
It probably makes no difference what context the Math functions are executed in, since they are probably backed by native code implementations that don't rely on context, but one could imagine some JavaScript implementation taking a shortcut and doing something like:
Math.exp = function(p) {
return this.pow(this.E, p);
}
assert(Math.exp(1), "Works");
assert(Math.exp.apply(Math, [1]), "Works");
var obj = {};
try {
Math.exp.apply(obj, [1]);
} catch(e) {
assert(false, "Doesn't work.");
}It also happens to be an excellent tutorial regardless of colors used.. =)
These are probably idioms you want to avoid writing in code if possible. Learning how to read them is probably useful some times.
I'm finding it a wonderfully interactive way to learn.