function and arguments as aguments

[RobG]

Re: function and arguments as aguments

Thomas 'PointedEars' Lahn wrote:
[...][color=blue]
>
> The test case
>
> Object.prototyp e.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 :)[/color]

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



--
Rob

[Thomas 'PointedEars' Lahn]

Re: function and arguments as aguments

Michael Winter wrote:
[color=blue]
> On 18/02/2006 01:16, ron.h.hall@gmai l.com wrote:[color=green]
>> In other words, it appears to me that the word 'original' should have
>> been removed in a couple of places, but was overlooked.[/color]
>
> 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 .[/color]

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


PointedEars

[Michael Winter]

Re: function and arguments as aguments

On 19/02/2006 02:21, Thomas 'PointedEars' Lahn wrote:
[color=blue]
> Michael Winter wrote:
>[color=green]
>> 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.[/color]
>
> 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.[/color]

I'm well aware of that. I never said it was a good thing.
[color=blue]
> 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).[/color]

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

As can I.

[snip]

Mike

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

[Michael Winter]

Re: function and arguments as aguments

On 19/02/2006 02:38, Thomas 'PointedEars' Lahn wrote:
[color=blue]
> Michael Winter wrote:[/color]

[Adding Array prototype methods to the Object prototype object]
[color=blue][color=green]
>> and in fact it would be inappropriate to do so (objects, in
>> general, are not shifted or joined).[/color]
>
> [...] Those methods manipulate the properties of objects with
> numerical name. [...][/color]

And the vast majority of native objects will never have numerical
properties or a length property that reflects the quantity of these
properties.
[color=blue]
> 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.[/color]

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.

[Michael Winter]

Re: function and arguments as aguments

On 19/02/2006 11:39, Thomas 'PointedEars' Lahn wrote:
[color=blue]
> Michael Winter wrote:
>[color=green]
>> On 18/02/2006 01:16, ron.h.hall@gmai l.com wrote:
>>[color=darkred]
>>> In other words, it appears to me that the word 'original' should have
>>> been removed in a couple of places, but was overlooked.[/color]
>>
>> 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 .[/color]
>
> 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.[/color]

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.

[Thomas 'PointedEars' Lahn]

Re: function and arguments as aguments

Michael Winter wrote:
[color=blue]
> On 19/02/2006 02:38, Thomas 'PointedEars' Lahn wrote:[color=green]
>> Michael Winter wrote:[/color]
> [Adding Array prototype methods to the Object prototype object][color=green][color=darkred]
>>> and in fact it would be inappropriate to do so (objects, in
>>> general, are not shifted or joined).[/color]
>> [...] Those methods manipulate the properties of objects with
>> numerical name. [...][/color]
>
> And the vast majority of native objects will never have numerical
> properties or a length property that reflects the quantity of these
> properties.[/color]

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?
[color=blue][color=green]
>> 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.[/color]
>
> Of course, but that doesn't mean that every native object should be
> given these methods.[/color]

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


PointedEars

[Lasse Reichstein Nielsen]

Re: function and arguments as aguments

Michael Winter <m.winter@bluey onder.co.uk> writes:
[color=blue]
> 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.[/color]

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.prototyp e wasn't always DontDelete and ReadOnly.


/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Thomas 'PointedEars' Lahn]

Re: function and arguments as aguments

Lasse Reichstein Nielsen wrote:
[color=blue]
> Michael Winter <m.winter@bluey onder.co.uk> writes:[color=green]
>> 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.[/color]
>
> 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.prototyp e wasn't always DontDelete and ReadOnly.[/color]

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

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

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

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


PointedEars

[ron.h.hall@gmail.com]

Re: function and arguments as aguments

Michael Winter wrote:[color=blue]
> On 19/02/2006 02:21, Thomas 'PointedEars' Lahn wrote:
>[color=green]
> > Michael Winter wrote:[/color][/color]
[...][color=blue][color=green]
> > 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).[/color]
>
> 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.
>[/color]

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.
[color=blue][color=green]
> > I can understand why _all_ implementors chose not to follow the
> > specification to the letter (t)here so far.[/color]
>
> As can I.
>[/color]

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

../rh

[VK]

Re: function and arguments as aguments


ron.h.hall@gmai l.com wrote:[color=blue]
> 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? :-).[/color]

But this "enlighteni ng 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.getEle mentById('p1');

alert(arguments .constructor.pr ototype.isProto typeOf(Object.c onstructor.prot otype));

alert(arguments .constructor.pr ototype.isProto typeOf(Function .constructor.pr ototype));

alert(arguments .constructor.pr ototype.isProto typeOf(String.c onstructor.prot otype));
// use as argument anything else you want
}

window.onload = init;
</script>

The dark secret of JavaScript (which you should keep in secret :-) is
that at the very bottom of everything it's the same class constructor
based language as any others. Prototyping is a *build-up* over it. But
this build up is implemented on so low generic level that you need
special efforts to see it.

[Thomas 'PointedEars' Lahn]

Re: function and arguments as aguments

VK wrote:
[color=blue]
> function init() {
> var out = document.getEle mentById('p1');
>
>[/color]
alert(arguments .constructor.pr ototype.isProto typeOf(Object.c onstructor.prot otype));[color=blue]
>[/color]

Yields true. Because:

arguments.const ructor.prototyp e.isPrototypeOf (
Object.construc tor.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.prototyp e (section 15.2.3.1).

It is implied that arguments.const ructor is Object().

=== Object.prototyp e.isPrototypeOf (Object.constru ctor.prototype)

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

=== Object.prototyp e.isPrototypeOf (Function.proto type)

And because of

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

O := Object.prototyp e;

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

V = Function.protot ype 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.protot ype.[[Prototype]] = Object.prototyp e

| 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.
[color=blue]
>[/color]
alert(arguments .constructor.pr ototype.isProto typeOf(Function .constructor.pr ototype));[color=blue]
>[/color]

Yields true, because of

arguments.const ructor.prototyp e.isPrototypeOf (
Function.constr uctor.prototype )

=== Object.prototyp e.isPrototypeOf (Function.proto type)
=== true

alert(arguments .constructor.pr ototype.isProto typeOf(String.c onstructor.prot otype));

Yields true, because of

arguments.const ructor.prototyp e.isPrototypeOf (
String.construc tor.prototype)

=== Object.prototyp e.isPrototypeOf (Function.proto type)
=== true
[color=blue]
> // 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. [...][/color]

Nonsense.


PointedEars

[Richard Cornford]

Re: function and arguments as aguments

VK wrote:
<snip>[color=blue]
> The dark secret of JavaScript (which you should keep in
> secret :-) ...[/color]
<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.