Whether the local object of the JavaScript can be modified (native object)

This article is translated from Rapydscript's author Alexander Tsepkov's blog.
Original address: http://blog.pyjeon.com/2014/05/17/modifying-native-javascript-objects/

Note: local objects (native object) refers to "objects provided by ECMAScript implementations that are independent of the hosting environment," such as Global and math.

In the JavaScript community, there has been a debate over the modification of JavaScript native objects (Array, number, String, object). Some developers think this is unacceptable, while others are very much in favor of it. If you have read the code for stdlib that Rapydscript (a precompiled compiler that supports writing JavaScript code like Python syntax), then you may already know where I stand, and I actually support making the appropriate changes when needed. In JavaScript, I may not have as many experience as the Masters, but I still have enough experience in judging the good or bad aspects of programming language design practice.

Most of the arguments are really weak, because they always take the developer to rewrite the local object itself, but there is no doubt that this is a bad thing. Imagine that if you do not know, but the invocation is still the same as the original implementation of the same parameters, then the result of execution is not the same. For example, I decided to String.prototype.replace rewrite it so that it could replace all occurrences in the same way as other languages, not just the first time:

Stringfunction(orig, sub) {    returnthis.split(orig).join(sub);}

In this case, the other code in the page would have thought that the logic of the replace library or component that would only replace the first element would be compromised, and that the code would no longer work in the way it was originally. Therefore, I totally disapprove of rewriting existing methods to do more things. So it's important to keep a basic subset of JavaScript language working the way everyone expects it to. For example, if you cannot guarantee that your house is based on a smooth foundation, then you cannot guarantee that it will not collapse.

But there are cases where we can just extend the functionality of the existing methods so that they can work in the way we originally wanted them to, while still doing something else when passing additional parameters:

Array . Prototype.pop = function   (index)  { if  (!. length) {index = this . Length-1; } return  this . Splice (Index, 1 ) [0 ];}  

Now, myArray.pop() you can still work in the same way, but if you call myArray.pop(0) , the function behaves the same as Myarray.shift () or the splice () function that passes the intermediate position index when called. In fact, the only downside to rewriting an existing function like this is that we make the function slower than the original function (the local function runs faster). But the reason to think that this rewriting of pop () is fundamentally bad is that it breaks another logic. That is to say that the call to pop () with a parameter is wrong (although the original function simply ignores the argument), or the call with arguments should be considered illegal. But in fact, the bug in the function is bad invocation, not logic when overriding the function. This is where I like Python, which reports immediately when parameters do not meet the requirements, rather than ignoring them and then having a bigger problem.

On the other side, adding new methods to local objects is a good way. Here are some examples of what we do:

Arrayfunction() {     returnthis.slice(); }

But in doing so, you should be aware that there are other libraries that have added methods with the same name but different functions. If you have one, you need to use a different name. If you cannot use more than one library or API set for a local object, this problem does not exist. So far, the main objection I know about the problem of modifying local objects is that JavaScript has the potential to add a method with the same name and cause a naming conflict in the future.

But you might notice that if you try to append a method to a local object object , all jquery-related code on the page does not work correctly. This problem is not caused by the rewriting of local methods. Instead, the jquery developer wrote the bug code under the wrong assumptions. JQuery developers are those who think that adding a method to a JavaScript local object is bad behavior, so for key in Object when you use the scan for object properties, you mistakenly assume that no one is appending to the object content, rather than correctly detecting whether it belongs to an object's own property. If you want to avoid making the same mistake as jquery, make sure that the iteration is only in the object's own keyword:

for (varin obj) {    if obj.hasOwnProperty(key) {        ...    }}

In addition, if you only care about using the latest browser, then you can also consider using Object.getOwnPropertyNames() to solve the problem.

In JavaScript, it's a bad design to iterate over every property of an object by default, but it can't be changed now. jquery developers have come up with this issue before, but they claim it is for performance reasons. Independent testing has shown that adding check code affects performance by only 5%, so I disagree with the assertion that this affects performance. Because jquery has already sacrificed too much performance for a good name (for example, show/hide logic checks the security of the object's current state). In my opinion, the position of John Resig (the father of jquery) on this issue is the same as not doing a 0 check (the automatic return in JavaScript infinity ) is the same, first claiming that this is for performance reasons, and then thinking that any method of passing parameter 0 to division is wrong.

I did not check if this issue was fixed in jquery 2.0. But for older browsers, Object.getOwnPropertyNames() there's no reason to not use them.

So, while using jquery, don't try to modify it anywhere Object (there's no problem with other local objects; Of course, if you don't use jquery, it's not a problem). Also, it is worth mentioning that if you are not going to support older browsers (such as IE8), it would be a better way to use defineproperty instead of adding methods to prototype. Because, when you iterate over an object, the methods you add in this way will be ignored. Then, the jquery bug won't exist.

As far as I'm concerned, I support adding functionality to local objects, but don't delete things on local objects. In addition, it is also a very bad way to change the way that an existing method works, but to use the same method signature, which is the same as removing the method. I removed the dependencies associated with overriding local object methods in the code of the Rapydscript STDLIB2 library. The main reason for this is to be consistent with jquery, so the standard library code is properly cleaned up. However, this does not mean that I object to modifying the code of local objects.

To learn more about Rapydscript, please visit rapydscript.cn.

Whether the local object of the JavaScript can be modified (native object)