"First, let's write the following: Object.prototype.clone"
Never, ever add things to Object.prototype. It breaks enumeration over objects using the for...in operator, which in turn breaks lots of other libraries you might want to use later. Sure, this is due to a bug in the core JavaScript spec but it's one we all have to live with.
You're correct, although it's worth noting that you can get around this problem in Rhino (Javascript on the Java VM). Steve Yegge talks about this in his semi-recent talk "Rhinos and Tigers": http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.ht...
There are many compelling reasons to stop using such a badly-implemented and rather-demented language; but unfortunately there are no compelling alternatives.
There are many compelling reasons to stop using such a badly-implemented and rather-demented language; but unfortunately there are no compelling alternatives.
If there are no alternatives, then those reasons start to look a lot less compelling.
I predict that web frameworks will emerge that will automate the writing of JavaScript in the same way they automate HTML creation. A sub-language with JS features but syntax like Ruby or Python will be silently compiled into the JS version when transmitted to the client.
8 comments
[ 2.7 ms ] story [ 29.5 ms ] threadNever, ever add things to Object.prototype. It breaks enumeration over objects using the for...in operator, which in turn breaks lots of other libraries you might want to use later. Sure, this is due to a bug in the core JavaScript spec but it's one we all have to live with.
There are many compelling reasons to stop using such a badly-implemented and rather-demented language; but unfortunately there are no compelling alternatives.
If there are no alternatives, then those reasons start to look a lot less compelling.
http://code.google.com/webtoolkit/
The future is here, man.