ES3.1 Draft: Array generics

[Douglas Crockford]

Maciej Stachowiak wrote:
> 
> On May 31, 2008, at 6:17 AM, Pratap Lakshman (VJ#SDK) wrote:
> 
>> [I'll take shot at replying (and Doug can clarify)]
>>
>> A feature that is present in 3 out of 4 browsers makes it a candidate 
>> for inclusion into ES3.1. However, that does not guarantee that it 
>> will get included.
>>
>> In the present case, here are a couple of data points:
>> (1) It was felt that providing the thisObj could potentially introduce 
>> a security issue.
>> (2) In ES3.1 we want to support Function.prototype.bind.
> 
> To counter that, I would mention:
> 
> (1) The 3 out of 4 browsers that currently support the "thisObj" 
> parameter, and I do not expect they would remove it, so the spec will be 
> incompatible with 3 out of 4 implementations.
> (2) Te proposed function.bind can be used to defend against this 
> rebinding, so the security issue can be avoided.
> (3) Many existing ECMAScript functions can be used to perform this 
> rebinding, including Function.prototype.call, Function.prototype.apply, 
> and the ES3.1 proposed Function.prototype.bind itself!
> 
> So, specifying map, filter, forEach etc as they are already implemented 
> in 3 out of 4 browsers does not create any consideration that does not 
> already exist, and the spec itself creates the means to mitigate it.
> 
>> Taken together, this led us to propose codifying Array generics as 
>> called out in the proposal I sent out (i.e. without the thisObj 
>> parameter). As Doug mentions below, apps could continue patching 
>> Array.prototype if they so desired, but going forward new apps should 
>> use bind instead of the thisObj.
> 
> If apps can redefine Array.prototype.map to do what existing 
> implementations do, doesn't that by definition mean the same security 
> issue still exists? Security is based on what bad things you *actually 
> can* do, not which are condoned by the spec as acceptable or which are 
> common practice. I imagine the reason "this" rebinding is of concern is 
> for secure dialects trying to prevent malicious code from doing it, not 
> to protect against someone doing accidentally.
> 
> Thus, I can't see a sound reason to be incompatible with existing practice.

I think we must implement the Array methods as currently understood, even with 
the regrettable thisObject parameter. The hazards of the misbinding of this are 
a particular problem for mashup platforms, so the use of the thisObject 
parameter will not be allowed in strict mode.

This will allow existing applications that use thisObject to continue to work, 
and it will also disable the thisObject pattern for new applications with more 
severe security requirements.