Array Generics and null

Brendan Eich brendan at
Sat Mar 29 11:05:00 PDT 2008

On Mar 22, 2008, at 10:18 PM, Mike Shaver wrote:

> On Sat, Mar 22, 2008 at 4:32 PM, Dean Edwards <dean at>  
> 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
>>>>,  ...).
>>> 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);

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?


More information about the Es4-discuss mailing list