ES3.1 Draft: Array generics

[Maciej Stachowiak]

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 mentiones 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.

Regards,
Maciej

> Kris Zyp then made the observation that apps on ES3.1 that relied on  
> feature-testing (before patching Array.prototype) would end up using  
> the 'incompatible' implementation was present! At that point, we  
> thought we would be better off not including the proposal for now.
>
> pratap
> PS: I'll have this on the agenda for further discussion in our next  
> conf. call.
>
> -----Original Message-----
> From: Maciej Stachowiak [mailto:mjs at apple.com]
> Sent: Saturday, May 31, 2008 2:22 AM
> To: Douglas Crockford
> Cc: Erik Arvidsson; es3.x-discuss at mozilla.org; Pratap Lakshman  
> (VJ#SDK); es4-discuss at mozilla.org
> Subject: Re: ES3.1 Draft: Array generics
>
>
> On May 20, 2008, at 7:35 AM, Douglas Crockford wrote:
>
>> Erik Arvidsson wrote:
>>> I know for a fact that not passing the thisObject as the third param
>>> in methods like map etc will break real world applications such as
>>> Gmail.  If JScript does not follow the defacto standard, developers
>>> will have to add detection for this anormality.  I think
>>> compatibility
>>> with other browser should be enough for ES3.1 to standardize that  
>>> the
>>> thisObject should be passed as the third parameter.
>>
>> I disagree. Gmail can continue patching Array.prototype as it does
>> now, so
>> nothing breaks. But going forward, new applications should be using
>> bind instead
>> of a thisoObject.
>
> I've heard it mentioned that ES3.1 has a "3 out of 4 browsers" rule.
> What exactly is the scope of this rule, and why does it not apply  
> here?
>
> Regards,
> Maciej
>