On Mar 22, 2008, at 10:18 PM, Mike Shaver wrote:
> On Sat, Mar 22, 2008 at 4:32 PM, Dean Edwards <[EMAIL PROTECTED]>
> wrote:
>> Dean Edwards wrote:
>>> I think that the problem is that Array generics were added later.
>>>
>>> From bugzilla:
>>>> Array.generic(t, ...) is *intended* to be equivalent to
>>>> Array.prototype.generic.call(t, ...).
>>>
>>> If generics were considered when first designing the language
>>> then the
>>> above statement would have been the other way round.
>>>
>>> e.g.
>>>
>>> Array.prototype.forEach = function(block, context) {
>>> Array.forEach(this, block, context);
>>> }
Just FYI, I don't think the argument order matters when discussing
the substitution of "the global object" for |this|. So to separate
those two, let's try to agree on the order of arguments in the
generic case matching, as if by arguments.shift(), the order for the
prototype counterparts. The order is a "sailed ship", IMHO.
>>>
>
> I don't see how that helps, unless you expect A.p.g.c(null, f) to
> differ from A.g(null, f) -- the former will need to make a |this| from
> null, giving the window object in browser embeddings. I don't believe
> that they should so differ -- do you?
There's an open issue in ES-future designs where we are trying to
agree not to replace null with the global object in the ES1-3
internal specification language, or anything equivalent, where
calling a function by its name, or by an expression without an
explicit reference base, results in |this| defaulting to null, for
which the spec and implementations then substitute "the global
object" before any scripted code can detect the null.
We would rather:
function topLevel(a,b,c) {
print(this, a, b, c);
}
topLevel(1,2,3);
print "undefined 1 2 3" than "[object global] 1 2 3".
This is incompatible, so it would happen only in some opt-in version,
or opt-in version + strict pragma enabled.
The issues are whether undefined or null should be the default
(undefined has won, AFAICT), and whether this is a migration tax
imposed by the new version when programmers opt in, or new version
plus 'use strict'.
Anyway, if we do this, we could change Function apply/call/bind and
the Array/String generic prototypes and their static counterparts to
eliminate this bad old null->global behavior. The library code could
stay as is, true -- the opt-in version +/- 'use strict' could affect
only top-level functions called without an explicit |this|. But it
seems better to make everything consistent in the "no global for null
substitution" sense. Comments?
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
