Re: ES3.1 Draft: Array generics
On Sat, May 31, 2008 at 3:37 PM, Douglas Crockford <[EMAIL PROTECTED]> wrote: > 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. Crock, I see no viable way to make this switchable on the strictness of the caller. We should try to avoid adding to the number of ways that built-in objects are magical -- able to do things that objects defined in JavaScript cannot. We have not proposed that a function/method be able to determine the strictness of its caller. I do not wish to propose that. Without it, I see no way to both introduce this API, but have it reject thisObject arguments only from strict callers. My first choice is still to avoid adding any of this. When in doubt, leave it out. But, as others have argued, none of this is fatal to security. If we're going to add it, we should provide the existing behavior as is, independent of the strictness of the caller. It won't hurt ADsafe or Cajita, since they don't have "this" at all. It will be a pain for Caja, but nothing we can't cope with. This one isn't worth fighting. -- Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Fwd: ES3.1 Draft: Array generics
fwd to list.
On Sat, May 31, 2008 at 1:44 AM, Garrett Smith <[EMAIL PROTECTED]> wrote:
> 2008/5/19 Pratap Lakshman (VJ#SDK) <[EMAIL PROTECTED]>:
> It would be sufficient and more correct to say: "throw a TypeError"
> rather than "throw a TypeError exception"
>
So it should probably read one of:-
1) If callbackfn does not implement [[Call]], throw a TypeError.
2) If callbackfn is not a function, throw a TypeError
There is also an absence of top-level generics:-
Array.forEach
- This avoids having to write:-
[].forEach.call( nodeList, fun );
Note on host objects:
Whether the forEach function can be applied successfully to a host
object is implementation -dependent.
- support Array Generics for host object, for example, a DOM NodeList
in abstract view.
[].sort.call( ul.getElementsByTagName("li"), byName );
Garrett
> Regards,
>
> Garrett
>
>> pratap
>>
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Draft: Array generics
On May 31, 2008, at 3:37 PM, Douglas Crockford wrote:
> 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.
So IIUC, in ES3.1 strict mode, given
var a = [1,2,3];
this is an error:
var b = a.map(function(e,i,a){print(e,i,a, this.z);return e}, {z:
42});
but this is not:
var b = a.map(function(e,i,a){print(e,i,a, this.z);return e}.bind
({z:42}));
Why is it ok to do something one (novel) way, but not another
(existing in 3 of 4 browsers) way?
That bind allocates an extra object may give the second way greater
integrity, but unless the function is stashed somewhere and called on
a different thisObject by other code, the above forms are equivalent.
The map implementation will only call the passed in function, and
only with the given or bound thisObject, once per existing (non-hole)
array element.
That bind require an extra (function) object to be allocated is
undesirable overhead, in the absence of threats.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Draft: Array generics
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. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Draft: Array generics
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
RE: Proposed ES4 draft 1
> -Original Message- > From: Garrett Smith [mailto:[EMAIL PROTECTED] > Sent: 31. mai 2008 01:29 > To: Lars Hansen > Cc: liorean; es4-discuss@mozilla.org > Subject: Re: Proposed ES4 draft 1 > > Hello, > > Does anyone else hate PDF? Would you prefer .doc? ;) > I want to be able to link to, and discuss this. PDF does not > allow me to do this. It is difficult to copy paste between pages. > > What is wrong with HTML? Nothing, and in fact the source document for the PDF is an HTML document, as you may have guessed. The main problem with posting that is that most browsers have problems with the CSS it uses, in my experience it only renders and prints correctly in some versions of Opera. The CSS could be broken and I'd appreciate corrections to it, but I suspect it's browsers lagging or getting it wrong. (On the other hand, Opera's printing subsystem raises all monospace fonts by a couple of points so the result is far from pretty. Sigh.) I'll look into putting the HTML up on ecmascript.org sometime this week. Thanks for bringing it up. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Ordering
2008/5/31 Douglas Crockford <[EMAIL PROTECTED]>: > This program... > > > > (function () { > var keys = [ > 'koda', 0, 'bosanda', 1, 'bosoya', 2 > ]; > > var object = {}, table, i, name; > > for (i = 0; i < keys.length; i += 1) { > object[keys[i]] = i; > } > > i = 0; > table = ''; > document.write(table); > })(); > > > > ...produces this result on current editions of Internet Explorer, Firefox, and > Safari: > > Insertion Order for in Order > kodakoda > 0 0 > bosanda bosanda > 1 1 > bosoya bosoya > 2 2 > > It produces this result for Opera: > > Insertion Order for in Order > koda0 > 0 1 > bosanda 2 > 1 koda > bosoya bosanda > 2 bosoya > > Opera appears to be optimizing array-like sequences. Opera stores property names that are array indexes in a more space efficient manner than other property names, at the cost of not preserving insertion order when enumerating the properties. > What should ES3.1 say about member ordering? Should it remain unordered, or > should Opera be required to conform, or should the other three be forced to > adopt Opera's optimization? ES4 requires enumeration order to follow insertion order, so the space optimisation Opera does break the ES4 rules. Opera have bugs about property access being a performance problem, and in the process of fixing that may change to another storage system, so aligning with Opera's current behaviour would be a bad idea. I think ES3.x should either follow ES4 or stay silent on the issue, especially considering Opera is the only browser that doesn't use insertion order enumeration. -- David "liorean" Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
'; > for (name in object) { > table += ' ' + > 'Insertion Order for inOrder'; > i += 1; > } > table += ' ' + keys[i] + ' ' + name + '
RE: ES3.1 Draft: Array generics
[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. 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. 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
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
Re: ES3.1 Draft: Array generics
2008/5/19 Pratap Lakshman (VJ#SDK) <[EMAIL PROTECTED]>: > I have uploaded to the wiki a draft proposal (link) for Array generics. > I have extracted the Array portion of the ES3 spec, added a rationale (with > hyperlinks) at the beginning, and made relevant changes to the included > section 15.4 text, with some comments added. I have tried to be mindful of > compat. > "If Type(callbackfn) is not a function, throw a TypeError exception." There is no function Type defined in ES 3.1. Are you incorporating the ES4 Type, or does callbackfn must implement [[Call]]? It would be sufficient and more correct to say: "throw a TypeError" rather than "throw a TypeError exception" As with my comment for ES4, there are many benefits to having the spec in HTML. It is easy to link directly to a fragment, it doesn't take a plugin, I don't get prompted to update Acrobat Reader, HTML is not slow to load as launching Reader is. But most of all, it is easier for the rest of the world to link to and discuss (if that is desirable to the committee) Regards, Garrett > pratap > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Proposed ES4 draft 1
Hello, Does anyone else hate PDF? I want to be able to link to, and discuss this. PDF does not allow me to do this. It is difficult to copy paste between pages. What is wrong with HTML? Garrett ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
