views:

172

answers:

4

Since it seems like the first thing people do is convert arguments into a real array, I'm interested in why the Javascript language authors and implementers decided, and continue to think, that arguments should not be a real Array. I don't mean this as flamebait, I'm sincerely interested in the thinking behind it. Since the function is naturally being called when you're in its body, I don't think it's because the objects arguments are referencing can change, like with some of the DOM results...

+4  A: 

It's important to note that without one of the designers present, we can only really conjecture why. But we can come up with some decent reasons... here's mine:

From the perspective of a function, one reason could be because you can't - obviously - actually change the arguments that were passed into you. You could change an array that represents the arguments passed into you, but the arguments as they were passed is set in stone before you ever receive execution scope.

You can splice, dice and pop arrays, and if you did that to the arguments object then you just ruined what is conceptually an immutable structure (sad face!). The design of the real arguments object is closer to a kind of immutability JavaScript can offer.

It is similar to querystring parameters. You get a collection handed to you by the client sending the request. It's part of the request information, which is already set and done.

Rex M
I'm not sure if I fully agree with the reasoning here. `arguments` is just an object, and although we can't technically change the actual arguments, we can do whatever we want to the entire `arguments` object or individual arguments it represents through array indices - `arguments[0]`, `arguments[1]`, ... Why wasn't it made an `Array` then, or given an array-like interface is still worth contemplating I'd say. Same problem applies to NodeList's.
Anurag
Rex and Anurag, both good points.
pr1001
@Anurag I don't necessarily disagree... as I said, we can only conjecture why, and this is my theory :)
Rex M
@Rex - good points, I think the option to create tamper-free objects in ES5 is a good step forward and `arguments` can make very good use of it. One reason I can think of for really basic interfaces is that the ES5 committee is basically responsible for the entire web when they make breaking changes, so they are slow and hard to come by unfortunately.
Anurag
+3  A: 

arguments doesn't just return the arguments. It returns callee object, and the array of arguments. If it were just an array, the first element might be the callee object and be more confusing.

Andir
Perhaps the question then should be, why isn't there a separate `callee` object? Why should be be a property of `arguments`?
pr1001
+4  A: 

The arguments object has the very unusual feature that its array-like elements are synonyms for the local variables that hold the function arguments. For example:

function f(x) {
   console.log(arguments[0]);   // Displays the initial value of the argument x
   x = 5;                       // Changes the value of the local variable x
   console.log(arguments[0]);   // Now displays 5
}

I always had the impression that this "magical behaviour" is the reason why arguments is not an array.

Daniel Vassallo
True, but I can also have `function a() { console.log(arguments) }; a(1, 2, 3);`...
pr1001
Yes, this behavious applies only when you have named arguments.
Daniel Vassallo
+1 - That's pretty darn magical...
gnarf
Fortunately this *linkage* has been removed under ES5 strict mode :) (I don't like magic!).
CMS
@CMS: I don't either :)... Do you think this is the reason why `arguments` was not implemented as an array?
Daniel Vassallo
@Daniel, posted my conjecture :)
CMS
@CMS: I see that you've posted your thoughts in a new answer :) Regarding ES5 strict mode, does it still allow changing the elements of the `arguments` object, or is it immutable?
Daniel Vassallo
@Daniel, nope, is not immutable, the only change in the `arguments` object itself (regardless the various semantic restrictions of the strict mode), is that its `[[Class]]` internal property contains the string `"Arguments"`, e.g.: `Object.prototype.toString.call(arguments) == "[object Arguments]";`.
CMS
this behavior could've been easily preserved by an appropriate `[[Put]]` internal method of the `arguments` array (for non-strict mode).
galambalazs
+8  A: 

My conjecture:

The concept of the arguments object has been on the language since the very beginning, it's even described in the ECMAScript First Edition Standard(PDF).

In that version of ECMAScript, the Array.prototype was really basic, array objects contained only 4 methods!: toString, join, reverse and sort.

I think that's one of the major reasons about they make arguments to inherit from Object.prototype, at that time those Array methods didn't look too useful.

But the Array.prototype object was extended in the next versions of the standard, now on ES5, Array objects have methods such as map, reduce, every, some, etc, that are really powerful.

The last year, there was a proposal in ES5 to make arguments inherit from Array.prototype, in the draft stages of the standard, but was dropped off time later.

In those drafts, arguments inherited from Array.prototype, but for backwards compatibility with ES3, the arguments object had defined two own properties, toString and toLocaleString, both pointing to the same methods on Object.prototype, but finally, the committee decided to keep inheriting from Object.prototype.

CMS
conjecture? looks like you were present in all those committee meetings.. lol
Anurag
And who was there doesn't know about it: http://www.slideshare.net/douglascrockford/newandimproved, nice wrap up btw +1. But it doesn't tell you **why** the committee " **continue** to think that `arguments` should not be a real `Array`"
galambalazs
@galambalazs: IMO the reason about why the committee decided that, it's about the *fear of breaking the web*, the ES5 standard was designed very carefully, avoiding any radical change, in fact no new syntax was introduced to the language. The proposal I talk about, IIRC was dropped out because they discussed about *extreme edge* cases of incompatibility, such as re-defining the `Object.prototype`. We'll see, maybe in the future...
CMS