On Sep 9, 2008, at 1:49 PM, Garrett Smith wrote:
On Tue, Sep 9, 2008 at 11:32 AM, Mark S. Miller
<[EMAIL PROTECTED]> wrote:
Should strict 'arguments' be an array? I know we've over this before
and that strong reasons were presented why we couldn't do this.
But on
the ES3.1 phone call this morning no one could remember or regenerate
those reasons. Anyone? Pointers to previous threads are a fine
answer.
There was a narrow-cast thread among ES3.1 principals, I replied
without enlarging it. Here's my last message in full, citing Allen's
agreement:
I only now noticed that this mail spun off from a narrowcast mail
from Pratap, but the topic (arguments' type) deserves a wider list.
[EMAIL PROTECTED] is fine. May be that we are done with
this thread, but if not (or if it comes back to life), it should
not be too narrowly distributed. There's always the TC39 reflector
for member-only stuff.
/be
On Aug 1, 2008, at 6:26 PM, Allen Wirfs-Brock wrote:
OK, I generally buy this, that arguments is an Object but its
[[prototype]] is Array.prototype. What about the semantics of its
length property and other array specific semantics defined in Array
instances’ custom [[Put]] method ([[ThrowablePut]] in the ES3.1
spec.). I would think--yes, which means we will need to define a
custom [[ThrowablePut]] for argument objects. That is probably
also the appropriate place for defining the mapping to/from actual
parameters semantics.
At least one thing in Array.prototype that doesn’t fit if arguments
is an Object and not an Array. That is the definition of
constructor in Array.prototype. We can fix that by explicitly
providing an over-riding constructor property on arguments
instances. Are there any other properties of Array.prototype that
need special consideration?
Finally, this brings to mind a subtlety to think about. The
Object meta functions can expose whether or not a property is an
own property or an inherited property. When the speciation says
(as it does in several places) that an instance of a specific
constructor has certain properties are we implying that those
properties must be observably own properties of the instance? From
an implementation flexibility perspective I’d prefer that this was
left unspecified but from an interoperability perspective I suppose
we should pin it down.
From: Brendan Eich [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2008 7:34 AM
To: Pratap Lakshman (VJ#SDK)
Cc: [EMAIL PROTECTED]; Mark S. Miller; Kris Zyp; Mike Cowlishaw;
Adam Peller; Sam Ruby; Lars Hansen; [EMAIL PROTECTED]; Allen Wirfs-
Brock; Waldemar Horwat
Subject: Re: ES3.1 WG phone conference 29 July 08:00 PT
On Jul 29, 2008, at 7:04 AM, Pratap Lakshman (VJ#SDK) wrote:
(3) arguments. I think we should make arguments a true ES array. We
should correct the specification error that allowed it to be
anything else.
This is not possible without extra magic, due to the aliasing of
arguments[0] and x in
function f(x){arguments[0] = 42; return x}
It goes both ways of course:
function f(x){x = 42; return arguments[0]}
You can't require analysis to find the mutation (of either alias),
due to eval. We shouldn't require any kind of analysis in ES3.1 to
handle this aliasing. It has to be done as it has always been done,
by a magic arguments object whose element getters know how to find
the actual parameters, and whose element setters update those
actuals that correspond to declared formal parameters.
Note that the last sentence requires the first call to f below to
return undefined, not 42:
js> function f(a,b){arguments[1]=42;return b}
js> f(1)
js> f(1,2)
42
For these reasons, arguments cannot be a true array. Such a change
is also not backward compatible in ways I recall Lars found out
about when he was at Opera.
The only harmonized solution is to make arguments' prototype be
Array.prototype. Let's please do that, or else leave arguments alone.
(4) Edits based on review feedback from Oslo; schedule for
circulating the next draft
Sorry if I cannot attend this meeting -- I will try if my schedule
permits. I'm still traveling and I haven't had a chance to dig into
chapter 15 of the spec. I hope the above is clear.
/be
Back to the present:
Thanks.
There are other threads covering arguments, not hard to find with
site:mail.mozilla.org or nabble.com (although both have odd gaps in
message indexing -- I'll talk to mail.mozilla.org admins).
The arguments object could have the same methods as array, like a
"subclass" of array, but not have the special [[Put]], and concat()
could still work the way it does with today's arguments object (I
don't actually prefer the current behavior)
The plan has been to make arguments objects delegate to Array.prototype.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
