Good, this thread caused me to identify another bug, step 4 of 10.5 (create the
arguments Object) currently sets the [[Constructor]] (???) internal property
to Object. It should be using [[DefineOwnProperty]] to set the "constructor"
property. This is necessary because Array.prototype specifically defines its
"constructor" property to be Array so it needs to be over-ridden.
I think we should try both of the suggestions in the ES3.1 candidate. The
[[Class]] of an arguments object should be "Arguments" and
Array.prototype.printString should be made generic.
However, that opens up two questions: exactly how to make Array.prototype's
printString generic and does arguments need its own over-ride to printString.
I think, a reasonable answer to the first, is to simply define
Array.prototype's printString to be generic and say it is as if it did
this.join(). For the second, I think arguments needs an over-ride that results
in "[object Arguments]" unless somebody wants to seriously argue that it should
have the this.join() behavior.
We (Mark?) should also carefully review the definition of Array.prototype's
methods to make sure there isn't any other unnecessary non-generic behavior
specified.
As a side note, if user code wanted to "reuse" Array.prototype the way we are
for the arguments object I would think the preferred way would be to create a
new prototype that inherits from Array.prototype such as:
MyArrayLikeConstructor.prototype =
Object.create(Array.prototype, {
constructor: {value: MyArrayLikeConstructor, writable:
true,configurable: true},
etc...}};
I'm not seriously suggesting (extra spec. work, unexplored implications of
reifying such a prototype) that we do the same for arguments objects but it
does feel like that would be a better design.
Allen
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
