«

wrote:
> Michael Winter wrote:
> > On 17/02/2006 18:42, Thomas 'PointedEars' Lahn wrote:
> >
> > [snip]
> >
> > > | 10.1.8 Arguments Object
> > > | [...]
> > > | * The value of the internal [[Prototype]] property of the
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > | arguments object is the original Object prototype object,
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > | the one that is the initial value of Object.prototype
> > > | (section 15.2.3.1).
> >
> > As I've always understood the 'original Object prototype' phrase, and it
> > seems rather explicit, above, the arguments object may only ever have
> > the properties as described in 15.2.3.1. That is, because it's
> > [[Prototype]] property is the /original/ Object prototype object,
> > modifications to that prototype will not be seen with an arguments
> > object. The fact that some implementations do use a modified Object
> > prototype object is a peculiarity of those implementations.
> >
>
> But to accept that position, 15.2.3.1:
>
> "Object.prototype - The initial value of Object.prototype is the
> Object prototype object (15.2.4)."
>
> which also seems rather explicit, has to be reconciled. If this is not
> an assignment of the original, it's a nebulous and extremely sloppy
> indication that it's actually a copy or an original that's, in turn, to
> remain completely pristine. Or do I misunderstand your interpretation
> of how the original would remain intact?
>
> > Note that the only other use of the phrase, 'original Object prototype
> > object', is found in the description of the [[Construct]] property
> > (13.2.2) where the original Object prototype object will be used if the
> > prototype property of the Function object is not an object.
> >
>
> This, then, raises the question of what possible reason would there be
> making this type of special condition of 'original inheritance only'
> for these two cases. And especially in the case of a Function object
> that doesn't happen to have an object as a prototype - why would
> something outside the mold of all other objects being created have to
> be used in this case?
>
> It doesn't add up. The whole thing has the appearance of something that
> was backed off in the production of the standard, but not completely.
> In other words, it appears to me that the word 'original' should have
> been removed in a couple of places, but was overlooked.

It adds up perfectly if we read Books of ECMA in the way it was
intended by Fathers, not in the after-Reformation way

All they wanted to say is that any possible object in JavaScript (as
well as in any other language thought) has at very beginning of its
evolution chain the Object object.
And at the very bottom of everything there is the original constructor
(object factory, allocator, God forgive me - class) producing that the
most primitive Object object.
Object Constructor is the very bottom of everything, there is nothing
below that except the "possibility that still has to become", "to ti en
einai" of Aristote

Something can be the very first in the chain, but nothing can appear
from nowhere. This is why there are objects without prototype, but
there are no objects without a constructor behind them.

So again they just wanted to say that the same "becomizator"
(constructor, class, allocator) used to produce Object object - the
same constructor is being used to produce <arguments> object.

Therefore <Object> object and <arguments> object are not in inheritance
relations, but they are both instances of the same class constructor.
Just no one expected that 7 years later will be a new generation of
JavaScript programmers (and doc readers) with mentally prohibited
ability to apply constructor / class terms to the text.

If we read apocryphal texts of the same or close time (1998-1999) we
shall see not see too many cases where "prototype" is used as
"something strictly opposed to the class". At that time "prototype"
stayed closer to the original more universal "a first form from which
varieties arise", this is why prototype vs. constructor terminology in
Books Of ECMA is not so strict as some modern readers would like it to
be.


Some fun to play with:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html401/frameset.dtd">
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<style type="text/css">
body { background-color: #FFFFFF}
</style>

<script type="text/javascript">
function init() {
alert (arguments instanceof Object); // true
alert(init.constructor instanceof Object); // true
}

window.onload = init;
</script>

</head>
<body>
<p>&nbsp;</p>
</body>
</html>

P.S. I did not check: was OP's question anywhere answered?

Michael Winter wrote:

> On 17/02/2006 18:42, Thomas 'PointedEars' Lahn wrote:
>> | 10.1.8 Arguments Object
>> | [...]
>> | * The value of the internal [[Prototype]] property of the
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> | arguments object is the original Object prototype object,
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> | the one that is the initial value of Object.prototype
>> | (section 15.2.3.1).
>
> As I've always understood the 'original Object prototype' phrase, and it
> seems rather explicit, above, the arguments object may only ever have
> the properties as described in 15.2.3.1.

Then you have to read it again, for you misunderstood it. Most
certainly because you read it not thoroughly enough.

Objects have a [[Prototype]] property that refers to the object they
inherit from.

Core objects, because they also expose themselves as constructors,
have also a `prototype' property that refers to an object O with
properties (their prototype object). The properties of O are
inherited through the prototype chain by objects which have their
[[Prototype]] property as referring to O, or, in other words, have
O as their [[Prototype]] property.

Those are two _different_ objects.

> That is, because it's [[Prototype]] property is the /original/ Object
> prototype object, modifications to that prototype will not be seen with
> an arguments object.

Wrong. If the [[Prototype]] property of an object is another object O,
which is equivalent to the term "refers to O" (remember the `==' and
`===' operators), it inherits all properties from that object through
the prototype chain.

The "(original) Object prototype object" is Object.prototype.

The "internal [[Prototype]] property of the Object prototype object"
^^^^^^^^^^^
is Object.prototype.[[Prototype]], which is null (end of the prototype
chain).

> The fact that some implementations do use a modified Object
> prototype object is a peculiarity of those implementations.

Wrong. It is because of a strict ECMAScript-conforming implementation in
that regard.

> Note that the only other use of the phrase, 'original Object prototype
> object', is found in the description of the [[Construct]] property
> (13.2.2) where the original Object prototype object will be used if the
> prototype property of the Function object is not an object.

You have to read the definitions in context. The specification is very
clear in that regard:

| 4.3.4 Constructor
|
| A constructor is a Function object that creates and initialises objects.
| Each constructor has an associated prototype object that is used to
| implement inheritance and shared properties.

Only constructors C have a native `prototype' object, C.prototype.

| 8.6.2 Internal Properties and Methods
|
| Native ECMAScript objects have an internal property called [[Prototype]].
| The value of this property is either null or an object and is used for
| implementing inheritance. Properties of the [[Prototype]] object are
| visible as properties of the child object for the purposes of get access,
| but not for put access.

All native objects O have an internal [[Prototype]] property,
O.[[Prototype]]. Properties _of_ O.[[Prototype]] are inherited
for "get access" through the prototype chain.

Those are _different_ concepts, and _different_ objects.

>> That means essentially that `arguments' is an Object object, as it
>> inherits directly from Object.prototype through the prototype chain.
>> Which makes it possible to augment Object.prototype and call its
>> methods with `arguments' as caller.
>
> Assuming for the moment that I'm correct, that would make this statement
> false: it /shouldn't/ be possible (except through extensions to the
> language) to use the properties of an augmented Object prototype object.
> [...]

Exactly. This is _proof_ /that/ you are wrong. I have explained
above /why/ you are wrong.

> A final, related note: the arguments object is an Array instance in Opera.

That appears to be true, and would be a conforming extension of ECMAScript:

| 2 Conformance
|
| A conforming implementation of ECMAScript must provide and support all the
| types, values, objects, properties, functions, and program syntax and
| semantics described in this specification.
| [...]
| A conforming implementation of ECMAScript is permitted to provide
| additional types, values, objects, properties, and functions beyond those
| described in this specification. [...]

It has Object.prototype in its prototype chain, though, through
Array.prototype.[[Prototype]] which is (or refers to) Object.prototype:

| 15.4.4 Properties of the Array Prototype Object
|
| The value of the internal [[Prototype]] property of the Array prototype
| object is the Object prototype object (section 15.2.3.1).

Which is why augmentation of Object.prototype or `arguments' itself works
there for `arguments', too.


HTH

PointedEars

On 18/02/2006 01:16, wrote:

> Michael Winter wrote:

[snip]

>> As I've always understood the 'original Object prototype' phrase
>> [...] the arguments object may only ever have the properties as
>> described in 15.2.3.1. That is, because it's [[Prototype]] property
>> is the /original/ Object prototype object, modifications to that
>> prototype will not be seen with an arguments object. [...]
>
> But to accept that position, 15.2.3.1:
>
> "Object.prototype - The initial value of Object.prototype is the
> Object prototype object (15.2.4)."
>
> which also seems rather explicit, has to be reconciled.

I don't believe that they conflict, as such, but...

> If this is not an assignment of the original, it's a nebulous and
> extremely sloppy indication that it's actually a copy [...]

....I do agree that it's not presented very well, and I think that this
is the crux of the problem. If I continue your quotation of 15.2.3.1, we
find:

This property has the attributes { DontEnum, DontDelete,
ReadOnly }.

which means that the Object.prototype property can never be deleted or
reassigned, yet the description of the property above uses the word,
'initial'. Why say that value of the property /begins/ with the Object
prototype object if that's the only value that it can ever have? The
inclusion of 'initial' is redundant at best, but without the attribute
description above, its implication is misleading.

[snip]

> This, then, raises the question of what possible reason would there be
> making this type of special condition of 'original inheritance only'
> for these two cases.

It is possible that this problem of language also applies to the use of
'original'. However, for the arguments object, I can't think of a
particular reason why one would want it to inherit properties from an
augmented Object prototype object.

> And especially in the case of a Function object that doesn't happen
> to have an object as a prototype - why would something outside the
> mold of all other objects being created have to be used in this case?

That's a question I can't answer. However, the absence of an object for
the prototype property would be a rather exceptional event, so perhaps
the language designers decided on an exceptional way of dealing with it.
I'm not the person to ask: I've only made an observation.

> It doesn't add up. The whole thing has the appearance of something that
> was backed off in the production of the standard, but not completely.

Perhaps, but of the possible places to retain the distinction, the two
cases that I pointed to are about the only reasonable parts of the
specification where this behaviour could be applied (the only other
possibility that I can see is the [[Prototype]] property of the Math
object).

The similar phrase, 'Object prototype object', occurs elsewhere in the
specification where the inheritance of used-defined properties would be
undoubtedly beneficial.

> In other words, it appears to me that the word 'original' should have
> been removed in a couple of places, but was overlooked.

It's quite a coincidence that only these two occurrences exist, and do
so in places where the lack of inheritance is more-or-less inconsequential.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

On 18/02/2006 12:32, Thomas 'PointedEars' Lahn wrote:

> Michael Winter wrote:

[snip]

>> As I've always understood the 'original Object prototype' phrase,
>> and it seems rather explicit, above, the arguments object may only
>> ever have the properties as described in 15.2.3.1.
>
> Then you have to read it again, for you misunderstood it.

Your opinion is noted, but I don't agree. The inclusion of the word
'original' alters the meaning of the sentence. It implies that the
Object prototype object can be modified (and we know it can), but the
value of the internal [[Prototype]] property of the arguments object is
to use the original. If it meant a possibly augmented object, it could
have omitted the word in question as the specification does in the
majority of other occurrences of the phrase.

Whether this situation was intended by the language designers is a
different matter entirely.

[snip]

> Objects have a [[Prototype]] property that refers to the object they
> inherit from.
>
> Core objects, because they also expose themselves as constructors,
> have also a `prototype' property that refers to an object O with
> properties (their prototype object). The properties of O are
> inherited through the prototype chain by objects which have their
> [[Prototype]] property as referring to O, or, in other words, have
> O as their [[Prototype]] property.
>
> Those are two _different_ objects.

I already know this.


The rest of your post (with some exceptions, below) hinges around your
understanding of the phrase 'original Object prototype object' and that
it differs from mine. As your other points derive from that, there's
little value in addressing them (I would be arguing against points that
I would otherwise agree with).

[snip]

>> Assuming for the moment that I'm correct, that would make this
>> statement [that the arguments object inherits from an augmented
>> Object prototype object] false: it /shouldn't/ be possible (except
>> through extensions to the language) to use the properties of an
>> augmented Object prototype object. [...]
>
> Exactly. This is _proof_ /that/ you are wrong.

No, it isn't. A proof that I was wrong would necessitate an statement
that corrects some misunderstanding of the word 'original' and its
implications in the context I have outlined.

original (adjective)

1. first or earliest
2. fresh and unusual; not copied from or based on something
else
3. able to think of or carry out new ideas or concepts
4. being the first and genuine form of something, from which a
copy or translation is made

Its use implies, intended or otherwise, that there may be a difference
between the object that exists during execution, and that described in
the specification.

In case you're confusing the issue, I'm not arguing that other native
objects (such as Function or String instances) cannot inherit from an
augmented 'Object prototype object'. The word 'original' is not included
with their use of that phrase.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Michael Winter wrote:

> [...] However, for the arguments object, I can't think of a particular
> reason why one would want it to inherit properties from an augmented
> Object prototype object.

Have you even read the thread? The whole point of this exercise was to
use methods of Array.prototype such as shift() and join() for `arguments'.
The goal was to achieve that always, not only if `arguments' (undoubtedly
as a conforming extension of ECMAScript) inherits from Array.prototype.

news:

>> And especially in the case of a Function object that doesn't happen
>> to have an object as a prototype -

Not true.

| 13.2 Creating Function Objects
|
| [...]
| 9. Create a new object as would be constructed by the expression new
| Object().
| [...]
| 11. Set the prototype property of F to Result(9). This property is
| given attributes as specified in section 15.3.5.2.
| [...]
| 15.3.2.1 new Function (p1, p2, ... , pn, body)
| [...]
| A prototype property is automatically created for every function, to
| provide for the possibility that the function will be used as a
| constructor.
| [...]
| 15.3.3 Properties of the Function Constructor
|
| The value of the internal [[Prototype]] property of the Function
| constructor is the Function prototype object (section 15.3.4).
|
| Besides the internal properties and the length property (whose value is
| 1), the Function constructor has the following properties:
|
| 15.3.3.1 Function.prototype
|
| The initial value of Function.prototype is the Function prototype object
| (section 15.3.4).
|
| This property has the attributes { DontEnum, DontDelete, ReadOnly }.
|
| 15.3.4 Properties of the Function Prototype Object
| [...]
|
| 15.3.5.2 prototype
|
| The value of the prototype property is used to initialise the internal
| [[Prototype]] property of a newly created object before the Function
| object is invoked as a constructor for that newly created object. This
| property has the attribute { DontDelete }.

The only difference here is that the phrase "Properties of the Function
Constructor" is used instead of the phrase "Properties of the Function
Object". However, since only constructors are specified to have a native
`prototype' property, regarding that property both phrases are equivalent.

>> why would something outside the mold of all other objects being created
>> have to be used in this case?
>
> That's a question I can't answer. However, the absence of an object for
> the prototype property would be a rather exceptional event, so perhaps
> the language designers decided on an exceptional way of dealing with it.
> I'm not the person to ask: I've only made an observation.

Another wrong observation at that.


PointedEars

On 19/02/2006 01:48, Thomas 'PointedEars' Lahn wrote:

> Michael Winter wrote:
>
>> [...] However, for the arguments object, I can't think of a
>> particular reason why one would want it to inherit properties from
>> an augmented Object prototype object.
>
> Have you even read the thread?

Considering that I contributed an answer to the OP, that's an extremely
stupid question to ask (rhetorically or otherwise). Please refrain from
remarks like that in the future, Thomas.

> The whole point of this exercise was to use methods of
> Array.prototype such as shift() and join() for `arguments'.

But augmentation of the Object prototype object is not necessary for
this, and in fact it would be inappropriate to do so (objects, in
general, are not shifted or joined).

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Michael Winter wrote:

> In case you're confusing the issue, I'm not arguing that other native
> objects (such as Function or String instances) cannot inherit from an
> augmented 'Object prototype object'. The word 'original' is not included
> with their use of that phrase.

If one was to follow this logic, and the specification to the letter, it
would mean that an implementation would have to retain both the "original
Object prototype object" (and keep memory allocated for it) and another
Object prototype object that can be subject to augmentation, just for the
sake of `arguments' which is not even needed if control never enters the
execution context for function code. Which also would have to apply for
the prototype objects of Function, Array, String, Boolean, Number, Date,
RegExp and Error objects as well, because this particular phrase is also
used in their definitions (ECMAScript 3 Final, 13.2, 13.2.2, 15.4.2.1,
15.4.2.2, 15.5.2.1, 15.6.2.1, 15.7.2.1, 15.9.3.1, 15.9.3.2, 15.9.3.3,
15.10.4.1, 15.11.1.1, and 15.11.2.1).

I can understand why _all_ implementors chose not to follow the
specification to the letter (t)here so far. If they did, it would have
rendered all augmentation of core object's prototype objects meaningless,
thereby reducing the flexibility of the language considerably, while
allocating more memory than needed in the usual case. That said, this
design decision is also entirely in conformance with ECMAScript.
We can live with it.


PointedEars

Michael Winter wrote:

> On 19/02/2006 01:48, Thomas 'PointedEars' Lahn wrote:
>> Michael Winter wrote:
>>> [...] However, for the arguments object, I can't think of a
>>> particular reason why one would want it to inherit properties from
>>> an augmented Object prototype object.
>>
>> Have you even read the thread?
>
> Considering that I contributed an answer to the OP, that's an extremely
> stupid question to ask (rhetorically or otherwise). [...]

No, it is not, given your extremely stupid statement above. (Hey, I am
only using your rhetoric...)

>> The whole point of this exercise was to use methods of
>> Array.prototype such as shift() and join() for `arguments'.
>
> But augmentation of the Object prototype object is not necessary for
> this,

But a viable and more efficient approach, since `arguments' is recreated
on every call. You are free to augment `arguments' only on each and
every method call; I prefer to consider other possibilities as well.

> and in fact it would be inappropriate to do so (objects, in general, are
> not shifted or joined).

Nonsense. Those methods manipulate the properties of objects with numerical
name. The property values are not necessarily object references. In fact,
the whole point of reusing methods of Array.prototype is to handle
properties of objects with numerical name as if they were array elements.

So instead of writing a for-loop that concatenates (or pushes to an array,
if you wish) the values of all properties with numerical name, you just
augment Object.prototype or the target object itself and call join() on
the target object with a feasible separator. There is undoubtedly an
uncompared elegance and efficiency to this programming style.


PointedEars

Michael Winter wrote:
> On 18/02/2006 01:16, wrote:
>
> > Michael Winter wrote:
>
> [snip]
>
> >> As I've always understood the 'original Object prototype' phrase
> >> [...] the arguments object may only ever have the properties as
> >> described in 15.2.3.1. That is, because it's [[Prototype]] property
> >> is the /original/ Object prototype object, modifications to that
> >> prototype will not be seen with an arguments object. [...]
> >
> > But to accept that position, 15.2.3.1:
> >
> > "Object.prototype - The initial value of Object.prototype is the
> > Object prototype object (15.2.4)."
> >
> > which also seems rather explicit, has to be reconciled.
>
> I don't believe that they conflict, as such, but...
>

Well, in my interpretation they do, because of the use of the word
'the' -- in my reading, and by general context provided by the
document, I'm inclined to take that as "the one, and the only". That
is, I don't see any suggested or specified way of maintaining an object
that holds the original properties.

In addition, it seems most reasonable in the generation of the initial
prototype hierarchy, that there be a single prototype object (with
internal [[Prototype]] that terminates in null) to serve as the mother
of all inheritance.

> > If this is not an assignment of the original, it's a nebulous and
> > extremely sloppy indication that it's actually a copy [...]
>
> ...I do agree that it's not presented very well, and I think that this
> is the crux of the problem. If I continue your quotation of 15.2.3.1, we
> find:
>
> This property has the attributes { DontEnum, DontDelete,
> ReadOnly }.
>
> which means that the Object.prototype property can never be deleted or
> reassigned, yet the description of the property above uses the word,
> 'initial'. Why say that value of the property /begins/ with the Object
> prototype object if that's the only value that it can ever have? The
> inclusion of 'initial' is redundant at best, but without the attribute
> description above, its implication is misleading.
>

I think it is redundant, but it's at the very least consistent with
indication of of initialization of properties that is used in the
specification. I've tended to read that as "initialized to", given the
usage, rather than taking implication regarding potential subsequent
mutation (that appear in some cases to be constrained by {Don't Delete}
and {Read Only}).

> [snip]
>
> > This, then, raises the question of what possible reason would there be
> > making this type of special condition of 'original inheritance only'
> > for these two cases.
>
> It is possible that this problem of language also applies to the use of
> 'original'. However, for the arguments object, I can't think of a
> particular reason why one would want it to inherit properties from an
> augmented Object prototype object.
>
> > And especially in the case of a Function object that doesn't happen
> > to have an object as a prototype - why would something outside the
> > mold of all other objects being created have to be used in this case?
>
> That's a question I can't answer. However, the absence of an object for
> the prototype property would be a rather exceptional event, so perhaps
> the language designers decided on an exceptional way of dealing with it.
> I'm not the person to ask: I've only made an observation.
>

Perhaps, but when ambiguity presents, I generally prefer to take the
path of least resistance; i.e., why try to make things more complicated
than absolutely necessary.

> > It doesn't add up. The whole thing has the appearance of something that
> > was backed off in the production of the standard, but not completely.
>
> Perhaps, but of the possible places to retain the distinction, the two
> cases that I pointed to are about the only reasonable parts of the
> specification where this behaviour could be applied (the only other
> possibility that I can see is the [[Prototype]] property of the Math
> object).
>
> The similar phrase, 'Object prototype object', occurs elsewhere in the
> specification where the inheritance of used-defined properties would be
> undoubtedly beneficial.
>
> > In other words, it appears to me that the word 'original' should have
> > been removed in a couple of places, but was overlooked.
>
> It's quite a coincidence that only these two occurrences exist, and do
> so in places where the lack of inheritance is more-or-less inconsequential.
>

Have to agree. That lends more weight to the consistency approach, as
opposed to creation of exceptions for reasons yet to be substantiated.

Thanks for the reasoned and reasonable response.

../rh

Thomas 'PointedEars' Lahn wrote:
[...]
>
> The test case
>
> Object.prototype.join = Array.prototype.join;
> (function() { alert(arguments.join("x")); })(1, 2, 3); // "1x2x3"
> alert({1: 2, 2: 3, length: 3}.join("x")); // "x2x3"
>
> works in the following user agents:
>
> - Mozilla Firefox 1.5.0.1
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060209
> Debian/1.5.dfsg+1.5.0.1-2 Firefox/1.5.0.1
>
> - Mozilla (Suite) 1.7.12
> [Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205
> Debian/1.7.12-1.1]
>
> - Netscape Navigator 4.8
> [Mozilla/4.8 [en] (X11; U; Linux 2.6.15.1-20060130.184242+0100 i686)]
>
> - Opera 8.51
> [Opera/8.51 (X11; Linux i686; U; en)]
>
> - Konqueror 3.5.1
> [Mozilla/5.0 (compatible; Konqueror/3.5;
> Linux 2.6.15.1-20060130.184242+0100; X11; i686; de, en_US)
> KHTML/3.5.1 (like Gecko) (Debian package 4:3.5.1-2)]
>
> IE, Windows, and Mac testers, it's your turn

Add Safari 1.0.3 (and later I guess), Firefox 1.5 and Opera 8.5 on Mac.



--
Rob