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:[EMAIL PROTECTED] > Sent: Saturday, May 31, 2008 2:22 AM > To: Douglas Crockford > Cc: Erik Arvidsson; [EMAIL PROTECTED]; Pratap Lakshman > (VJ#SDK); es4-discuss@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 > _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
