448,689 Members | 1,106 Online
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
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

 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

 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 caninvoke a string containing java script code. the solution that seemedintuitive 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 faras 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'tthink 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 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 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" 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. 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" 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. 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 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 object. Therefore

 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 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 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: 'Faith without judgement merely degrades the spirit divine.' Feb 20 '06 #37

 P: n/a Lasse Reichstein Nielsen wrote: Michael Winter 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 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: 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; 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: The dark secret of JavaScript (which you should keep in secret :-) ... 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.