arguments-object prototype

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

re: arguments-object prototype

Florian Loitsch wrote:
[color=blue]
> [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?[/color]

The former: the value that is present before any user code is
executed, and therefore any alterations that might be made.
[color=blue]
> In the latter case: why would the write "initial", if it can't be
> changed anyways (ReadOnly)?[/color]

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.
[color=blue]
> Example:
> ===
> Object.prototype.x = "prototype-x";
> function f()
> {
> alert(arguments.x);
> }
> f(); // "prototype-x" or undefined ?
> ===[/color]

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

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

re: arguments-object prototype

Michael Winter wrote:
[snip][color=blue]
> 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.[/color]
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

re: arguments-object prototype

Florian Loitsch wrote:

[snip]
[color=blue]
> not trying to bitch,[/color]

Bitch all you want. :)
[color=blue]
> but how can this not be a violation?[/color]

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.
[color=blue]
> 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).[/color]

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

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

re: arguments-object prototype

On Tue, 15 Mar 2005 16:25:00 +0100, Florian Loitsch
<news@florian.loitsch.com> wrote:
[color=blue]
>Michael Winter wrote:
>[snip][color=green]
>> 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.[/color]
>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).[/color]

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

Jim.

re: arguments-object prototype

Michael Winter wrote:[color=blue]
> Florian Loitsch wrote:
>[color=green]
> > [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?[/color]
>
> The former: the value that is present before any user code is
> executed, and therefore any alterations that might be made.
>[color=green]
> > In the latter case: why would the write "initial", if it can't be
> > changed anyways (ReadOnly)?[/color]
>[/color]

<..>
[color=blue][color=green]
> > Example:
> > ===
> > Object.prototype.x = "prototype-x";
> > function f()
> > {
> > alert(arguments.x);
> > }
> > f(); // "prototype-x" or undefined ?
> > ===[/color]
>
> It should be undefined,[/color]

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

re: arguments-object prototype

rh wrote:
[color=blue][color=green]
>> Florian Loitsch wrote:
>>[color=darkred]
>>> [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".[/color][/color][/color]

[snip]
[color=blue][color=green][color=darkred]
>>> Object.prototype.x = "prototype-x";
>>> function f()
>>> {
>>> alert(arguments.x);
>>> }
>>> f(); // "prototype-x" or undefined ?[/color][/color][/color]

[snip]
[color=blue]
> 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.[/color]

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

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

re: arguments-object prototype

Michael Winter wrote:[color=blue]
> rh wrote:[/color]

<..>
[color=blue][color=green]
> > 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.[/color]
>
> 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.
>[/color]

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