function and arguments as aguments

VK · Feb 18, 2006

Michael said:
Michael said:

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).

Click to expand...

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.

Click to expand...

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.

Click to expand...

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> </p>
</body>
</html>

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

Thomas 'PointedEars' Lahn · Feb 18, 2006

Michael said:
| 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).

Click to expand...

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.

Click to expand...

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

Michael Winter · Feb 19, 2006

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. [...]

Click to expand...

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 · Feb 19, 2006

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.

Click to expand...

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. [...]

Click to expand...

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

Thomas 'PointedEars' Lahn · Feb 19, 2006

Michael said:
[...] 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.

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.

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

Michael Winter · Feb 19, 2006

Michael said:
Michael said:

[...] 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.

Click to expand...

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

Thomas 'PointedEars' Lahn · Feb 19, 2006

Michael said:
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

Thomas 'PointedEars' Lahn · Feb 19, 2006

Michael said:
Michael said:

[...] 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.

Click to expand...

Have you even read the thread?

Click to expand...

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...)

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

ron.h.hall · Feb 19, 2006

Michael said:
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. [...]

Click to expand...

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.

Click to expand...

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 [...]

Click to expand...

...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.

Click to expand...

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?

Click to expand...

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.

Click to expand...

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.

Click to expand...

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

RobG · Feb 19, 2006

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.

Thomas 'PointedEars' Lahn · Feb 19, 2006

Michael said:
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.

As I have noted elsewhere, this is _wrong_. The phrase "original ...
prototype object" occurs far more than two times in the specification.
To state that the lack of inheritance would be (more or less)
inconsequential there, is ridiculous.

PointedEars

Michael Winter · Feb 19, 2006

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.

I'm well aware of that. I never said it was a good thing.

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).

And this is a significant observation that I hadn't made.

Whilst there is no doubt in my mind what the wording still implies, this
would demonstrate that Ron is correct in that the word 'original' should
have been removed from all occurrences of the 'original ... prototype
object' phrase.

I can understand why _all_ implementors chose not to follow the
specification to the letter (t)here so far.

As can I.

[snip]

Mike

Michael Winter · Feb 19, 2006

Michael Winter wrote:

[Adding Array prototype methods to the Object prototype object]

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

Click to expand...

[...] Those methods manipulate the properties of objects with
numerical name. [...]

And the vast majority of native objects will never have numerical
properties or a length property that reflects the quantity of these
properties.

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.

Of course, but that doesn't mean that every native object should be
given these methods.

[snip]

Mike

Michael Winter · Feb 19, 2006

As I have noted elsewhere, this is _wrong_. The phrase "original ...
prototype object" occurs far more than two times in the specification.
To state that the lack of inheritance would be (more or less)
inconsequential there, is ridiculous.

Quite, but that doesn't invalidate my observation. It only serves to
indicate that the specification is badly worded.

Mike

Thomas 'PointedEars' Lahn · Feb 19, 2006

Michael said:
Michael Winter wrote:

Click to expand...

[Adding Array prototype methods to the Object prototype object]

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

Click to expand...

[...] Those methods manipulate the properties of objects with
numerical name. [...]

Click to expand...

And the vast majority of native objects will never have numerical
properties or a length property that reflects the quantity of these
properties.

The prototype object augmentation does not only affect core objects but
also objects that inherit from them. Who is to say what properties those
objects might have?

Of course, but that doesn't mean that every native object should be
given these methods.

That would depend on the field of application, of course.

PointedEars

Lasse Reichstein Nielsen · Feb 20, 2006

Michael Winter said:
Whilst there is no doubt in my mind what the wording still implies,
this would demonstrate that Ron is correct in that the word 'original'
should have been removed from all occurrences of the 'original
... prototype object' phrase.

I agree that it can be confuzing, since it is unnecessary.
My guess is that it is a leftover from the development of ECMA262,
where perhaps Object.prototype wasn't always DontDelete and ReadOnly.

/L

Thomas 'PointedEars' Lahn · Feb 20, 2006

Lasse said:
I agree that it can be confuzing, since it is unnecessary.
My guess is that it is a leftover from the development of ECMA262,
where perhaps Object.prototype wasn't always DontDelete and ReadOnly.

Unfortunately, your assumption is not supported by the texts of ECMA-262
Edition 1 and Edition 2. In both specifications, the definition of
Object.prototype is exactly the same as in Edition 3 (with more or less
indentation):

| 15.2.3.1 Object.prototype
|
| The initial value of Object.prototype is the built-in Object prototype
| object (15.2.4).
|
| This property shall have the attributes { DontEnum, DontDelete,
| ReadOnly }.

If your assumption would apply, that development process you refer to
would have to be an earlier working draft of ECMA-262, and a very
sloppy standardization process at that. I find that hard to believe,
given that ECMA-262-3 is also approved as ISO/IEC 16262.

However, I am pretty sure that this wording started with ECMA-262 and was
never questioned in the development of later editions. Since it is not
even in the ECMA-262-3 errata, it is either intentionally, and all
implementors decided against implementing this so far, or not, which would
mean that "one should" add this as an erratum. However, I would not know
how to accomplish that.

PointedEars

ron.h.hall · Feb 20, 2006

Michael said:
Michael Winter wrote: [...]
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).

Click to expand...

And this is a significant observation that I hadn't made.

Whilst there is no doubt in my mind what the wording still implies, this
would demonstrate that Ron is correct in that the word 'original' should
have been removed from all occurrences of the 'original ... prototype
object' phrase.

Actually, (as much as I would hate to contradict myself ;-)), I suppose
the wording would remain technically correct, because it is the
'original'. But it seems to be agreed that it is highly misleading,
given the implication that is natural to adopt from use of this
qualification. It certainly would have been better to have been much
less explicit, rather than over-specifying, in this instance.

As can I.

But as you pointed out earlier, at least one implementor appears to
have chosen to go one step further and expose 'arguments' as an Array
object. As much as strict adherence to the specification is to be
desired, given the nature of 'arguments', and the *truly minimal*
actual fundamental difference between Object objects and Array objects,
I think Opera got it right. I would have preferred to see that be the
specification -- but then, I suppose generic methods wouldn't have come
up, we wouldn't have had much of this enlightening discussion, would
we?

.

../rh

VK · Feb 20, 2006

Actually, (as much as I would hate to contradict myself ;-)), I suppose
the wording would remain technically correct, because it is the
'original'. But it seems to be agreed that it is highly misleading,
given the implication that is natural to adopt from use of this
qualification. It certainly would have been better to have been much
less explicit, rather than over-specifying, in this instance.

But as you pointed out earlier, at least one implementor appears to
have chosen to go one step further and expose 'arguments' as an Array
object. As much as strict adherence to the specification is to be
desired, given the nature of 'arguments', and the *truly minimal*
actual fundamental difference between Object objects and Array objects,
I think Opera got it right. I would have preferred to see that be the
specification -- but then, I suppose generic methods wouldn't have come
up, we wouldn't have had much of this enlightening discussion, would
we? .

But this "enlightening discussion" still brought many to even further
confusion IMHO, because everyone wanted to read out of the text (indeed
rather badly written - I have to admit that) something it doesn't
contain.

"Original" end of world, the brick wall of the border of the universe:

<script type="text/javascript">
function init() {
var out = document.getElementById('p1');

alert(arguments.constructor.prototype.isPrototypeOf(Object.constructor.prototype));

alert(arguments.constructor.prototype.isPrototypeOf(Function.constructor.prototype));

alert(arguments.constructor.prototype.isPrototypeOf(String.constructor.prototype));
// use as argument anything else you want
}

window.onload = init;
</script>

The dark secret of JavaScript (which you should keep in secret

is
that at the very bottom of everything it's the same class constructor
based language as any others. Prototyping is a *build-up* over it. But
this build up is implemented on so low generic level that you need
special efforts to see it.

Thomas 'PointedEars' Lahn · Feb 20, 2006

VK said:
function init() {
var out = document.getElementById('p1');

alert(arguments.constructor.prototype.isPrototypeOf(Object.constructor.prototype));

Yields true. Because:

arguments.constructor.prototype.isPrototypeOf(
Object.constructor.prototype)

| 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).

It is implied that arguments.constructor is Object().

=== Object.prototype.isPrototypeOf(Object.constructor.prototype)

Because Object() is a (constructor) function, its constructor property is
Function():

=== Object.prototype.isPrototypeOf(Function.prototype)

And because of

| 15.2.4.6 Object.prototype.isPrototypeOf (V)
|
| When the isPrototypeOf method is called with argument V, the following
| steps are taken:
|
| 1. Let O be this object.

O := Object.prototype;

| 2. If V is not an object, return false.

V = Function.prototype is an object, nothing done.

| 3. Let V be the value of the [[Prototype]] property of V.

| 15.3.4 Properties of the Function Prototype Object
|
| [...]
| The value of the internal [[Prototype]] property of the
| Function prototype object is the Object prototype object
| (section 15.3.2.1).

V := Function.prototype.[[Prototype]] = Object.prototype

| 4. If O and V refer to the same object or if they refer to objects joined
| to each other (section 13.1.2), return true.

O === V, return true.

alert(arguments.constructor.prototype.isPrototypeOf(Function.constructor.prototype));

Yields true, because of

arguments.constructor.prototype.isPrototypeOf(
Function.constructor.prototype)

=== Object.prototype.isPrototypeOf(Function.prototype)
=== true

alert(arguments.constructor.prototype.isPrototypeOf(String.constructor.prototype));

Yields true, because of

arguments.constructor.prototype.isPrototypeOf(
String.constructor.prototype)

=== Object.prototype.isPrototypeOf(Function.prototype)
=== true

// use as argument anything else you want

}

window.onload = init;
</script>

The dark secret of JavaScript (which you should keep in secret is
that at the very bottom of everything it's the same class constructor
based language as any others. [...]

Nonsense.

PointedEars

C program: memory leak/ segmentation fault/ memory limit exceeded	0	Nov 12, 2022
How can I calculate the last payment for Reprofiled Amount column with 2 decimal places to make the sum of all payments to be the same as RC amount?	2	Jul 13, 2023
Need Help: Program to Accept 2 Matrices and Show their Sum	0	Aug 21, 2022
How do I position these parts?	4	Jan 6, 2024
MDP Modeling in GAMS	1	Mar 10, 2023
Trouble with prediction code, for the life of me I can't figure out why it isnt running properly. Help would be appreciated.	0	Jul 8, 2023
Ordenate and remove duplicate cases of an array passed as a c function argument	0	Sep 27, 2022
How can I click on an entry of my Kendo/Telerik Grid and show more detailed information in a Detail view?	0	Sep 13, 2022

function and arguments as aguments

VK

Thomas 'PointedEars' Lahn

Michael Winter

Michael Winter

Thomas 'PointedEars' Lahn

Michael Winter

Thomas 'PointedEars' Lahn

Thomas 'PointedEars' Lahn

ron.h.hall

RobG

Thomas 'PointedEars' Lahn

Michael Winter

Michael Winter

Michael Winter

Thomas 'PointedEars' Lahn

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn

ron.h.hall

VK

Thomas 'PointedEars' Lahn

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads