Augmenting Built-in (i.e. Native or Host) prototypes is generally
built-in object and Host object have distictly different meanings.
Augmenting a built-in object is considerably safer, in that the
outcome is likely to be defined by the EcmaScript 262 spec.
For example:
Error.prototype.toString = function() {
return this.name + ": " + this.message;
};
The "toString" property of Error.prototype is not defined as
ReadOnly.
It's not the most polite thing to do, in that it may interfere with
someone else's toString, so it's a good idea to at least make sure
you've got a broken feature before fixing it.
var result = Error.prototype.toString.call({name:"test"});
if(result == "[object Error]") {
// fix.
}
Augmenting Host object, OTOH, is not really defined by any standard
and results will vary from browsers and versions.
javascript:var e =
document.body.__proto__;void(e.__defineGetter__("clientTop",
function() { return -1; }));alert(document.body.clientTop)
Safari3: alert "0"
Firefox3 alert "-1"
There is no official standard for "clientTop" or if it is present on
any element, if it should be an instance property, a getter in the
prototype, et c.
considered a bad practice. It has burned many library authors (e.g.
Prototype.js authors) who have done it because it gives them a warm
fuzzy feeling to see some particular syntax. "Don't modify objects you
don't own" is commonly good advice.
It is a very powerful technique.
It's not standardized.
"Don't modify objects you don't own" is good advice. Modifying
HTMLElement.prototype to add on extra features that can be used by
each element sort of puts the new functionality in the wrong place,
sometimes even causing a collision (like as in above, or could be with
a "document.getElementsByClassName" collision). It's not safe.
Garrett