arguments-object prototype

[Florian Loitsch]

hi,
in section 10.1.8 (Arguments Object) it is stated that the "internal
[[Prototype]] property of the arguments object is the orginal Object
prototype object, the one that is the *initial* [emphasize mine] value of
Object.prototype".
Furthermore the Object.prototype property has attributes [DontEnum,
DontDelete, *ReadOnly*].
My question now: what does the "initial" refer to? To the untouched
prototype-object, or to the current Object.prototype? In the latter case:
why would the write "initial", if it can't be changed anyways (ReadOnly)?
Example:
===
Object.prototype.x = "prototype-x";
function f()
{
alert(arguments.x);
}
f(); // "prototype-x" or undefined ?
===
I'm aware, that all existing implementations I tested this example on
(Mozilla, Rhino, Konqueror), print "prototype-x". (but unfortunately they
aren't always right either...)
// florian

 

[Michael Winter]

[T]he "internal [[Prototype]] property of the arguments object is
the orginal Object prototype object, the one that is the *initial*
[emphasize mine] value of Object.prototype".

Furthermore the Object.prototype property has attributes [DontEnum,
DontDelete, *ReadOnly*].

My question now: what does the "initial" refer to? To the untouched
prototype-object, or to the current Object.prototype?

The former: the value that is present before any user code is
executed, and therefore any alterations that might be made.

In the latter case: why would the write "initial", if it can't be
changed anyways (ReadOnly)?

The ReadOnly attribute only applies to the particular property. In
this case, Object.prototype. It means that the prototype object cannot
be completely replaced...

/* Will silently fail: */
Object.prototype = {
myMethod : function() {}
};

....but the properties of the prototype object are not automatically
read-only. They too must have their individual attributes set.

Example:
===
Object.prototype.x = "prototype-x";
function f()
{
alert(arguments.x);
}
f(); // "prototype-x" or undefined ?
===

It should be undefined, however it's not likely to be a specification
violation. In section 2 - Conformance, it is stated that a conforming
implementation must provide the types and semantics within the
specification, but it does go on to say that an implementation may
provide extensions.

[snip]

Mike

 

[Florian Loitsch]

Michael Winter wrote:
[snip]

It should be undefined, however it's not likely to be a specification
violation. In section 2 - Conformance, it is stated that a conforming
implementation must provide the types and semantics within the
specification, but it does go on to say that an implementation may
provide extensions.

not trying to bitch, but how can this not be a violation? If it's explicitly
stated in the spec, and the implementation provides something different, it
must be a violation as it violates the semantics (IMHO).
// florian

 

[Michael Winter]

Florian Loitsch wrote:

[snip]

not trying to bitch,

Bitch all you want.

but how can this not be a violation?

I didn't say it wasn't, and perhaps "not likely" was saying too much.
Actually, my first draft implied that it was a violation, but some
self-doubt changed it to what I posted. Having read section 2 about
six more times since then, I'm inclined to believe that it is a violation.

Even if this is the case, that doesn't really mean much unless the
implementation is described as "conforming" when it isn't. Then either
the current behaviour should be labelled a bug and corrected in a
future release, or "conforming" should be removed from the description.

If it's explicitly stated in the spec, and the implementation
provides something different, it must be a violation as it violates
the semantics (IMHO).

It depends whether differing, but in most ways similar, semantics are
classed as an acceptable extension. Going back to my original
thoughts, I don't think they are.

Mike

 

[Jim Ley]

Michael Winter wrote:
[snip]

It should be undefined, however it's not likely to be a specification
violation. In section 2 - Conformance, it is stated that a conforming
implementation must provide the types and semantics within the
specification, but it does go on to say that an implementation may
provide extensions.

not trying to bitch, but how can this not be a violation? If it's explicitly
stated in the spec, and the implementation provides something different, it
must be a violation as it violates the semantics (IMHO).

Not really, the ECMAScript ed. 3 spec is extremely open about
extensions, adding new functionality is almost always allowed.

Jim.

 

[rh]

[T]he "internal [[Prototype]] property of the arguments object is
the orginal Object prototype object, the one that is the *initial*
[emphasize mine] value of Object.prototype".

Furthermore the Object.prototype property has attributes [DontEnum,
DontDelete, *ReadOnly*].

My question now: what does the "initial" refer to? To the untouched
prototype-object, or to the current Object.prototype?

The former: the value that is present before any user code is
executed, and therefore any alterations that might be made.

In the latter case: why would the write "initial", if it can't be
changed anyways (ReadOnly)?

Example:
===
Object.prototype.x = "prototype-x";
function f()
{
alert(arguments.x);
}
f(); // "prototype-x" or undefined ?
===

It should be undefined,

Seems to me it should be "prototype-x".

"arguments" is an object that has constructor "Object". arguments will
therefore inherit from the prototype, Object.prototype.

<..>

../rh

 

[Michael Winter]

[T]he "internal [[Prototype]] property of the arguments object
is the orginal Object prototype object, the one that is the
*initial* [emphasize mine] value of Object.prototype".

[snip]
[snip]

Seems to me it should be "prototype-x".

"arguments" is an object that has constructor "Object". arguments
will therefore inherit from the prototype, Object.prototype.

Is that after your interpretation of the first paragraph you quoted,
written by Florian? I'm certain that no additional properties should
be present, but I'm happy to be proved wrong.

Mike

 

[rh]

rh wrote:


Is that after your interpretation of the first paragraph you quoted,
written by Florian? I'm certain that no additional properties should
be present, but I'm happy to be proved wrong.

Well, perhaps it was after my mis-interpretation of that paragraph. In
reading it with more care, and ignoring much contrasting browser
behaviour, I think your take is the correct one.

../rh