Well written, clear syntax highlighted examples. Upboat.
JavaScript Garden
11–20 of 51 posts
Re: JavaScript Garden
#12Does anyone have an idea of what happened to "The secrets of the JavaScript ninja"? I'm impatiently waiting for this book to be released.
It's in review (I'm an occasional Manning reviewer and have looked at this recently).
Re: JavaScript Garden
#13Does anyone have an idea of what happened to "The secrets of the JavaScript ninja"? I'm impatiently waiting for this book to be released.
It's in review (I'm an occasional Manning reviewer and have looked at this recently).
Can we know, when this is going to be released? Not looking for a precise date, just a range.
Re: JavaScript Garden
#14the native prototypes should never be extended unless it is for the sake of compatibility with newer JavaScript features
A bit controversial, don't you think?
Re: JavaScript Garden
#15Excellent write-up! I've learned most of these things the hard way :/ I'm filing this away to recommend to any developers who are setting out to use Javascript extensively for the first time.
One quibble: In the "common pitfalls" section regarding the "this" object, they say that locally-defined functions within other functions never have any practical use. I might disagree: with a little coaxing, you can convince locally variables inside the constructor (both functions and other variables) to serve as private properties of an object; this is the only technique I know that allows for private properties.
(I haven't actually done this in code that has been maintained/used anywhere, I just did it as an experiment and filed it away as a "that's cool" for future reference)
Edit: Here is an example of what I'm talking about: https://gist.github.com/866103
Re: JavaScript Garden
#16In the prototype example [1], could someone explain the point or at least the effect of setting Bar.prototype.constructor = Bar? 1. http://bonsaiden.github.com/JavaScript-Garden/#prototype
A couple of lines up you see this:
Bar.prototype = new Foo();
So when you create a new instance of Bar, it's constructor still appears to be Foo even though it really isn't. Setting the prototype.constructor fixes that.
Re: JavaScript Garden
#17the native prototypes should never be extended unless it is for the sake of compatibility with newer JavaScript features A bit controversial, don't you think?
I think it's more of an issue of who is doing the extending. If it's your own code in a non shared library, then it's up to you.
If it's in a shared library, it is probably nicer to avoid. For instance, if you override a function on a native prototype, you might be overwriting some future function that browsers will implement. I've seen this done with Array.map for instance.
Re: JavaScript Garden
#18Excellent write-up! I've learned most of these things the hard way :/ I'm filing this away to recommend to any developers who are setting out to use Javascript extensively for the first time. One quibble: In the "common pitfalls" section regarding the "this" object, they say that locally-defined functions within other functions never have any practical use. I might disagree: with a little coaxing, you can convince lo…
Be careful of that. There is a trap right there. Your example is using the "new" keyword and not executing the function. So what happened?
1. If you use the "new" keyword, and don't execute the function. "x = new foo()". X becomes an "object". "foo()" is behaving like a class. You got to define the properties and methods of this class with the "this" keyword. Once you create your object with the "new" keyword, these variables got assigned to the object. And better, you can access them with the prototype.
2. If you execute the function in your code, that is you put "foo()": Open your FireFox with FireBug and notice two new global variables in the Windows object "get_my_private" and "set_my_private".
So it depends on the usage. "this" insides of a function is useful, if your intent is to use the function as a class. If not, it's dangerous, as the variables becomes global and may interfere with other variables.
Re: JavaScript Garden
#19the native prototypes should never be extended unless it is for the sake of compatibility with newer JavaScript features A bit controversial, don't you think?
I think it's more of an issue of who is doing the extending. If it's your own code in a non shared library, then it's up to you. If it's in a shared library, it is probably nicer to avoid. For instance, if you override a function on a native prototype, you might be overwriting some future function that browsers will implement. I've seen this done with Array.map for instance.
This is the case with extensions/inheritence in all the OO languages. You are supposed to verify that your extended library works, once you upgrade the base library.
Re: JavaScript Garden
#20Earlier quoted context omitted.
It's in review (I'm an occasional Manning reviewer and have looked at this recently).
Can we know, when this is going to be released? Not looking for a precise date, just a range.
There's some info about the status and estimated publishing date at http://www.manning.com/resig/