By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,689 Members | 1,106 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,689 IT Pros & Developers. It's quick & easy.

function and arguments as aguments

P: n/a
Hi. I have the following code:

--------------------------------------
function Tunnel() {
//arguments[0](???);
}

function Sum() {
var sum = 0;
for (i=0; i<arguments.length; i++) sum += arguments[i];
alert(sum);
};

// calling Sum directly
Sum(1,2,3,4);

// calling Sum through Tunnel
Tunnel(Sum, 1,2,3,4);
--------------------------------------

How should the Tunnel function be defined, knowing that the number of
parameters passed are unknown?

telmo
Feb 15 '06 #1
Share this Question
Share on Google+
41 Replies


P: n/a
You would be better off designing Sum to take an array as an argument,
then you can just pass the array of arguments to Sum

Feb 15 '06 #2

P: n/a
UnaCoder wrote:
You would be better off designing Sum to take an array as an argument,
then you can just pass the array of arguments to Sum


I was looking for a generic solution. But I presume for your replay that
there is no direct solution (at least no direct solution known by you
;) ).

Feb 15 '06 #3

P: n/a
Well I thought there was and I researched java script to see if you can
invoke a string containing java script code. the solution that seemed
intuitive would be to do something like:

function Tunnel() {
function_name= arguments[0];
arguments.shift(); args = arguments.join();
eval function_name + "(" + args + ");";
}

I didn't put any error checking in there, or test that code, but as far
as I know that should work =)

Feb 15 '06 #4

P: n/a
On 15/02/2006 17:42, Telmo Costa wrote:

[snip]
// calling Sum directly
Sum(1,2,3,4);

// calling Sum through Tunnel
Tunnel(Sum, 1,2,3,4);
--------------------------------------

How should the Tunnel function be defined, knowing that the number of
parameters passed are unknown?


The previous suggestion - rewrite the Sum function to take an array
argument - is preferable as it's the simplest and most compatible
solution. However, there is an alternative: the Function.prototype.apply
method.

function tunnel(func) {
return func.apply(null,
Array.prototype.slice.call(arguments, 1));
}
function sum() {
var total = 0,
i = arguments.length;

while (i--) {
total += arguments[i];
}
return total;
}

alert(tunnel(sum, 1, 2, 3, 4)); /* 10 */

The problem with this approach is that not all browsers, especially IE
with a pre-5.5 JScript library, do not implement either the
Function.prototype.apply or call methods. Though both can be emulated,
it requires quite a significant (though relatively trivial) amount of
work to accommodate a general case.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Feb 15 '06 #5

P: n/a
UnaCoder wrote:
Well I thought there was and I researched java script to see if you can
invoke a string containing java script code. the solution that seemed
intuitive would be to do something like:

function Tunnel() {
function_name= arguments[0];
arguments.shift(); args = arguments.join();
eval function_name + "(" + args + ");";
}

I didn't put any error checking in there, or test that code, but as far
as I know that should work =)

I always think of eval function as cheating :) Michael's solution is
more what i was looking for.

To be honest, the function i'm working with only takes 1 argument, so it
is like using the array solution. I was just wondering.

Nevertheless, thank you both.

Feb 16 '06 #6

P: n/a
UnaCoder wrote:
Well I thought there was and I researched java script to see if you can
invoke a string containing java script code. the solution that seemed
intuitive would be to do something like:

function Tunnel() {
function_name= arguments[0];
arguments.shift(); args = arguments.join();
eval function_name + "(" + args + ");";
}

I didn't put any error checking in there, or test that code, but as far
as I know that should work =)


Arguments is not an array, it's just a list with a few other properties
that make it look a bit like an array. Consequently, it doesn't have
split() or join() methods (and I don't think you can add them to its
prototype).
--
Rob
Feb 16 '06 #7

P: n/a
Telmo Costa wrote:
Hi. I have the following code:

--------------------------------------
function Tunnel() {
//arguments[0](???);
}

function Sum() {
var sum = 0;
for (i=0; i<arguments.length; i++) sum += arguments[i];
alert(sum);
};

// calling Sum directly
Sum(1,2,3,4);

// calling Sum through Tunnel
Tunnel(Sum, 1,2,3,4);
--------------------------------------

How should the Tunnel function be defined, knowing that the number of
parameters passed are unknown?


How about:

function tunnel()
{
this.sum = function(x){
var s=x[0], i=x.length;
while (--i) s += x[i];
return s;
}
this.product = function(x){
var s=x[0], i=x.length;
while (--i) s *= x[i];
return s;
}

var funcName = arguments[0];
var ar = [];
for (var i=1, len=arguments.length; i<len; ++i) {
ar[ar.length] = arguments[i];
}
return this[funcName](ar);
}

alert(tunnel('sum', 1, 2, 3, 4)); /* 10 */
alert(tunnel('product', 1, 2, 3, 4)); /* 24 */
Note that the function (e.g. sum) name needs to be passed as a string.
--
Rob
Feb 16 '06 #8

P: n/a
>
How about:

function tunnel()
{
this.sum = function(x){
var s=x[0], i=x.length;
while (--i) s += x[i];
return s;
}
this.product = function(x){
var s=x[0], i=x.length;
while (--i) s *= x[i];
return s;
}

var funcName = arguments[0];
var ar = [];
for (var i=1, len=arguments.length; i<len; ++i) {
ar[ar.length] = arguments[i];
}
return this[funcName](ar);
}

alert(tunnel('sum', 1, 2, 3, 4)); /* 10 */
alert(tunnel('product', 1, 2, 3, 4)); /* 24 */
Note that the function (e.g. sum) name needs to be passed as a string.

That won't do.

I'm building a XUL application (but could be HTML) and, at some point, I
need to start a couple of XMLHTTPRequest objects (using your examples,
sum and product will generate a XMLHTTPRequest object). Everything
worked ok, but now I have a restriction from the remote server: one
request at a time. I could make synchronous XMLHTTPRequests, but it will
froze the application.

So, I thought of a "tunnel" function that could work as a
synchronization point, where i build a queue of request and dispatch one
at a time. This way, the impact in the rest of the code is minimal.

Feb 16 '06 #9

P: n/a
RobG wrote:
UnaCoder wrote:
Well I thought there was and I researched java script to see if you can
invoke a string containing java script code. the solution that seemed
intuitive would be to do something like:

function Tunnel() {
function_name= arguments[0];
arguments.shift(); args = arguments.join();
eval function_name + "(" + args + ");";
}

I didn't put any error checking in there, or test that code, but as far
as I know that should work =)
Arguments is not an array, it's just a list


s/list/(Object) object/
with a few other properties that make it look a bit like an array.
Consequently, it doesn't have split() or join() methods (and I don't
think you can add them to its prototype).


Since `arguments' inherits directly from Object (ECMASCript 3 Final,
10.1.8), it is possible to add them, e.g.:

Object.prototype.join = function(delim)
{
var a = [];

for (var i = 0, len = this.length; i < len; i++)
{
a.push(this[i]);
}

return a.join(delim);
}

However, it is also an Object object without the ReadOnly attribute, so you
can add the methods to it instead, e.g.

arguments.join = function(delim)
{
/* see above */
}

The second approach would work for only one execution context, though, as
the `arguments' object is (re-)created and initialized every time control
enters an execution context for function code.

I have tested both approaches positive in Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.8) Gecko/20060110 Debian/1.5.dfsg-4 Firefox/1.5.
PointedEars
Feb 16 '06 #10

P: n/a
Thomas 'PointedEars' Lahn wrote:
[...]
Since `arguments' inherits directly from Object (ECMASCript 3 Final,
10.1.8), it is possible to add them, e.g.:

Object.prototype.join = function(delim)
{
var a = [];

for (var i = 0, len = this.length; i < len; i++)
{
a.push(this[i]);
}

return a.join(delim);
}

[...]

But since Array.prototype.join is generic (under ECMASCript 3), it
seems you should be able to use the built-in here, given that
'arguments': has a length and "numeric" properties:

Object.prototype.join = Array.prototype.join;

../rh

Feb 16 '06 #11

P: n/a
ro********@gmail.com wrote:
Thomas 'PointedEars' Lahn wrote:
Since `arguments' inherits directly from Object (ECMASCript 3 Final,
10.1.8), it is possible to add them, e.g.:

Object.prototype.join = function(delim)
{
var a = [];

for (var i = 0, len = this.length; i < len; i++)
{
a.push(this[i]);
}

return a.join(delim);
}


But since Array.prototype.join is generic (under ECMASCript 3), it
seems you should be able to use the built-in here, given that
'arguments': has a length and "numeric" properties:

Object.prototype.join = Array.prototype.join;


Indeed. Thank you for pointing this out. When reading only

,-[ECMAScript Edition 3 Final]
|
| 15.4.4.5 Array.prototype.join (separator)
|
| The elements of the array are converted to strings, [...]
^^^^^^^^^^^^^^^^^^^^^^^^^

it is easy to overlook the following at the top of the next page
(PDF version):

| NOTE The join function is intentionally generic; it does not require that
| its `this' value be an Array object. Therefore, it can be transferred to
| other kinds of objects for use as a method. Whether the join function
| can be applied successfully to a host object is implementation-dependent.

(It should be noted *g* that there is such a NOTE for other methods of
Array.prototype too.)

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 :)
PointedEars
Feb 16 '06 #12

P: n/a
Thomas 'PointedEars' Lahn wrote:
RobG wrote:

UnaCoder wrote:
Well I thought there was and I researched java script to see if you can
invoke a string containing java script code. the solution that seemed
intuitive would be to do something like:

function Tunnel() {
function_name= arguments[0];
arguments.shift(); args = arguments.join();
eval function_name + "(" + args + ");";
}

I didn't put any error checking in there, or test that code, but as far
as I know that should work =)


Arguments is not an array, it's just a list


s/list/(Object) object/


Yes, a list Object.

with a few other properties that make it look a bit like an array.
Consequently, it doesn't have split() or join() methods (and I don't
think you can add them to its prototype).


Since `arguments' inherits directly from Object (ECMASCript 3 Final,
10.1.8), it is possible to add them, e.g.:


The way I read the spec was that arguments shares the Object prototype,
which is null. I concluded that you couldn't add to it - clearly an
incorrect conclusion. :-x

I'll run the test in your other post later on a few Mac OS browsers.
--
Rob
Feb 17 '06 #13

P: n/a
VK

Thomas 'PointedEars' Lahn wrote:
ro********@gmail.com wrote:
Thomas 'PointedEars' Lahn wrote:
Since `arguments' inherits directly from Object (ECMASCript 3 Final,
10.1.8), it is possible to add them, e.g.:

Object.prototype.join = function(delim)
{
var a = [];

for (var i = 0, len = this.length; i < len; i++)
{
a.push(this[i]);
}

return a.join(delim);
}


But since Array.prototype.join is generic (under ECMASCript 3), it
seems you should be able to use the built-in here, given that
'arguments': has a length and "numeric" properties:

Object.prototype.join = Array.prototype.join;


Indeed. Thank you for pointing this out. When reading only

,-[ECMAScript Edition 3 Final]
|
| 15.4.4.5 Array.prototype.join (separator)
|
| The elements of the array are converted to strings, [...]
^^^^^^^^^^^^^^^^^^^^^^^^^

it is easy to overlook the following at the top of the next page
(PDF version):

| NOTE The join function is intentionally generic; it does not require that
| its `this' value be an Array object. Therefore, it can be transferred to
| other kinds of objects for use as a method. Whether the join function
| can be applied successfully to a host object is implementation-dependent.

(It should be noted *g* that there is such a NOTE for other methods of
Array.prototype too.)

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


It works in JScript 5.6 (IE 6.0)

For the purity of picture :-) one should say that in JScript
"arguments" is an objects with non-enumerable properties "length",
"callee", "caller" and "00"..."0X"
Besides that "00"..."0N of arguments" properties are *protected* so you
can access them only by numeric index, so say arguments[1] is really an
access to the property arguments['01'] which is not accessible
otherwise. Overall it looks like HTMLCollection where scring property
access is locked. That is the reason why it is stated in docs that
"arguments is not an array despite it looks like one" (because it's
indeed not).

Feb 17 '06 #14

P: n/a
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 :)


It appears to also work on IE 5.5 and IE 6.
Feb 17 '06 #15

P: n/a
RobG wrote:
Thomas 'PointedEars' Lahn wrote:
RobG wrote:
UnaCoder wrote:
Well I thought there was and I researched java script to see if you can
invoke a string containing java script code. the solution that seemed
intuitive would be to do something like:

function Tunnel() {
function_name= arguments[0];
arguments.shift(); args = arguments.join();
eval function_name + "(" + args + ");";
}

I didn't put any error checking in there, or test that code, but
as far as I know that should work =)
Arguments is not an array, it's just a list s/list/(Object) object/


Yes, a list Object.


There is no such thing.
with a few other properties that make it look a bit like an array.
Consequently, it doesn't have split() or join() methods (and I don't
think you can add them to its prototype).

Since `arguments' inherits directly from Object (ECMASCript 3 Final,
10.1.8), it is possible to add them, e.g.:


The way I read the spec was that arguments shares the Object prototype,


You misunderstood it.

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

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.

And since there are is no constraint for `arguments' regarding this,
it is possible, as with any Object object, to augment it directly.
Since it has been pointed out that Array.prototype.join and other
methods of Array.prototype are generic, direct augmentation is
indeed of practical value:

function x()
{
arguments.join = Array.prototype.join;
alert(arguments.join(","));
}

Only the current `arguments' object would be affected by it then,
not other Object objects. (Think about iterating through their
properties with `for..in'.)
which is null. [...]
No, fortunately it is not :) There would not be such nice properties
as `constructor' and methods as toString() otherwise. You are confusing
the prototype object and its [[Prototype]] property:

| 15.2.3.1 Object.prototype
|
| The initial value of Object.prototype is the Object prototype object
| (section 15.2.4).
|
| This property has the attributes { DontEnum, DontDelete, ReadOnly }.

The last attribute means essentially that you cannot overwrite the value of
Object.prototype with a reference to another object as that would break the
prototype chain mechanism preserved by the following:

| 15.2.4 Properties of the Object Prototype Object
|
| The value of the internal [[Prototype]] property of the Object prototype
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| object is null [...]

Hopefully this helps (you) to see the difference:

arguments.[[Prototype]] --> Object.prototype
Object.prototype --> {constructor: ..., toString: ..., ...}
Object.prototype.[[Prototype]] --> null
I'll run the test in your other post later on a few Mac OS browsers.


Thanks in advance.
Regards,
PointedEars
Feb 17 '06 #16

P: n/a
VK wrote:
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 :)
It works in JScript 5.6 (IE 6.0)


OK, thanks.
For the purity of picture :-) one should say that in JScript
"arguments" is an objects with non-enumerable properties "length",
"callee", "caller"
That is ECMAScript-compliant, except of the `caller' property. It is
identical to JavaScript before version 1.3. Since that version, the
latter property is only a property of the called Function object;
otherwise the implementation is identical.
and "00"..."0X"
I seriously doubt that.
Besides that "00"..."0N of arguments" properties are
protected so you can access them only by numeric index
How did you get /that/ idea anyway?
so say arguments[1] is really an access to the property arguments['01']
Most certainly it is not.
which is not accessible otherwise.
Because it does not exist. The property name is '1', not '01', as all
property names are strings and number-value names provided in bracket
property accessors are converted to string before the actual property
access occurs.
Overall it looks like HTMLCollection where scring property access
is locked.
It does not look like an HTMLCollection object at all. There is no
namedItem() and no item() method, and removing one element does not
change following key-value relationships.

"String property access" (whatever that might be) is not locked with
HTMLCollection objects. It is only that the type of the argument to
the property accessor defines which one of the methods, namedItem()
[for strings] or item() [for numbers] is actually called.

Try

arguments.join = Array.prototype.join;
alert(arguments.join(","));

If that works in function code, `arguments' is not "locked" in any way.
I am confident that this applies. So I dare say, without having tested
it in IE, assigning 42 to arguments['01'] will most certainly get you 42
for arguments['01'] but of course not for arguments['1'] or arguments[1]
in JScript, too. Because those are _different_ properties.
That is the reason why it is stated in docs that "arguments is not
an array despite it looks like one" (because it's indeed not).


That is not the reason why. The reason is that it does show certain
features of Array-ness, such as properties with numeric name and a `length'
property, but lacks others, such as the join() and split() methods. Even
with an Array object referred to by identifier `a', assigning to a['01']
would not add an element to the array.

ISTM that your problem is that you have still not understood Array objects,
and property accesses in general.

BTW, you could have trimmed your quotes.
PointedEars
Feb 17 '06 #17

P: n/a
VK

Thomas 'PointedEars' Lahn wrote:
Besides that "00"..."0N of arguments" properties are
protected so you can access them only by numeric index
How did you get /that/ idea anyway?


JScript 5.6 Language Reference

"arguments Object"

<quote>
You cannot explicitly create an arguments object. The arguments object
only becomes available when a function begins execution. The arguments
object of the function is not an array, but the individual arguments
are accessed the same way array elements are accessed. The index n is
actually a reference to one of the 0n properties of the arguments
object.
</quote>
ISTM that your problem is that you have still not understood Array objects,
and property accesses in general.


It is mostly your problem as you still did not get that ECMAScript
specs is a technical description of an engine which is gone years ago
(NN 4.5) so the next generations could reproduce its *behavior* if they
decide so. The *real* internal mechanics mimicing a particular behavior
may have nothing in common (and often it hasn't) with the mechanics of
NN as it was in 1999.

IE does it this way, FF this way, someone else may in other way. It is
not really important *most of the time* as long as the top level
behavior seems "as spelled".

Feb 17 '06 #18

P: n/a
VK wrote:
Thomas 'PointedEars' Lahn wrote:
> Besides that "00"..."0N of arguments" properties are
> protected so you can access them only by numeric index

How did you get /that/ idea anyway?


JScript 5.6 Language Reference

"arguments Object"

<quote>
You cannot explicitly create an arguments object. The arguments object
only becomes available when a function begins execution. The arguments
object of the function is not an array, but the individual arguments
are accessed the same way array elements are accessed. The index n is
actually a reference to one of the 0n properties of the arguments
object.
</quote>


Given your posting history, you should not even try to patronize me. This
is *obviously* a typo. It should read "0...n", for "0 to n", because it
goes on with:

| [...]
| See Also
|
| Reference
|
| 0...n Properties (JScript 5.6)
| [...]

Do I have anything more to say?
ISTM that your problem is that you have still not understood Array
objects, and property accesses in general.


It is mostly your problem as you still did not get that ECMAScript
specs is a technical description of an engine which is gone years
ago (NN 4.5) [snipped further nonsense]


Hear, hear!
PointedEars
Feb 17 '06 #19

P: n/a
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.

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.
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.
So, whilst:

arguments.join = Array.prototype.join;
arguments.join();

and:

Array.prototype.join.call(arguments);

would be acceptable:

Object.prototype.join = Array.prototype.join;
arguments.join();

is dubious.

[snip]

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

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Feb 17 '06 #20

P: n/a
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.

../rh

Feb 18 '06 #21

P: n/a
VK

ro********@gmail.com 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? :-)

Feb 18 '06 #22

P: n/a
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
Feb 18 '06 #23

P: n/a
On 18/02/2006 01:16, ro********@gmail.com 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.
Feb 19 '06 #24

P: n/a
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.
Feb 19 '06 #25

P: n/a
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:56****************@PointedEars.de
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
Feb 19 '06 #26

P: n/a
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.
Feb 19 '06 #27

P: n/a
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
Feb 19 '06 #28

P: n/a
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
Feb 19 '06 #29

P: n/a
Michael Winter wrote:
On 18/02/2006 01:16, ro********@gmail.com 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

Feb 19 '06 #30

P: n/a
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
Feb 19 '06 #31

P: n/a
Michael Winter wrote:
On 18/02/2006 01:16, ro********@gmail.com wrote:
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.


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
Feb 19 '06 #32

P: n/a
On 19/02/2006 02:21, Thomas 'PointedEars' Lahn wrote:
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.


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
Prefix subject with [News] before replying by e-mail.
Feb 19 '06 #33

P: n/a
On 19/02/2006 02:38, Thomas 'PointedEars' Lahn wrote:
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).


[...] 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
Prefix subject with [News] before replying by e-mail.
Feb 19 '06 #34

P: n/a
On 19/02/2006 11:39, Thomas 'PointedEars' Lahn wrote:
Michael Winter wrote:
On 18/02/2006 01:16, ro********@gmail.com wrote:
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.


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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Feb 19 '06 #35

P: n/a
Michael Winter wrote:
On 19/02/2006 02:38, Thomas 'PointedEars' Lahn wrote:
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).

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


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


That would depend on the field of application, of course.
PointedEars
Feb 19 '06 #36

P: n/a
Michael Winter <m.******@blueyonder.co.uk> writes:
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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Feb 20 '06 #37

P: n/a
Lasse Reichstein Nielsen wrote:
Michael Winter <m.******@blueyonder.co.uk> writes:
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.


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
Feb 20 '06 #38

P: n/a
Michael Winter wrote:
On 19/02/2006 02:21, Thomas 'PointedEars' Lahn wrote:
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).


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.
I can understand why _all_ implementors chose not to follow the
specification to the letter (t)here so far.


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

Feb 20 '06 #39

P: n/a
VK

ro********@gmail.com wrote:
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.isPrototypeO f(Object.constructor.prototype));

alert(arguments.constructor.prototype.isPrototypeO f(Function.constructor.prototype));

alert(arguments.constructor.prototype.isPrototypeO f(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.

Feb 20 '06 #40

P: n/a
VK wrote:
function init() {
var out = document.getElementById('p1');

alert(arguments.constructor.prototype.isPrototypeO f(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.isPrototypeO f(Function.constructor.prototype));
Yields true, because of

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

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

alert(arguments.constructor.prototype.isPrototypeO f(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
Feb 20 '06 #41

P: n/a
VK wrote:
<snip>
The dark secret of JavaScript (which you should keep in
secret :-) ...

<snip>

You have made it clear that you 'program' on the basis of mystical
incantation and voodoo; fabricating you own complex web of
'explanations' for the phenomenon you mis-observe and chanting bizarre
sequences of operators, function calls and statements to you computer in
the hope that it will do something resembling what you want, but without
any ability to explain why you are using them.

This subject is not magic, there are no secrets (dark or otherwise),
just mechanism; pure deterministic mechanical logic. Seeing yourself as
the priest of some esoteric lore and sole knower or the ultimate truth
will only get in the way of your understanding of javascript. After all,
you claim to have been using javascript since the late 1990s, probably
longer than the majority of the regular contributors to this group, and
yet you understand less than people who have only been doing this for
just a couple of years. And you constantly see (but cannot express)
arcane significance in features that are no more than the direct
consequence of the specified mechanism.

Richard.
Feb 20 '06 #42

This discussion thread is closed

Replies have been disabled for this discussion.