Discuss
  • Static Array and String Generics and Host Objects (ATTN IE Team)

Static Array and String Generics and Host Objects (ATTN IE Team)

# Garrett Smith (15 years ago)

Static Array and String Generics was an ES4 proposal[0], and is implemented in Mozilla JavaScript 1.6[1].

What are the plans for including Array and String Generics in future revision of ES?

There is no new syntax needed to support this. Scripts today can be compatible by adding:-

if(!Array.slice) { Array.slice= function( arrayLike, start, end ) { return Array.prototype.slice.call( arrayLike, start||0, end||arrayLike.length); }; }

However, there is a remaining problem there: No guaranteed behavior with Host object and Errors in IE. Example: javascript:alert( [].slice.call( document.childNodes ) );

Error in IE8: "JScript Object Expected".

It would be best for IE to use Native object for Host objects. That way, unwanted surprises like the above error should be done away with.

Array and String generics are useful for non-array objects.

The outcome of [].slice.call() should be determinable. It is up to public-script coord to define what happens when a Host object is used in an Array.

Brendan's 7-month-old message[2] asking for IE to comment on Array generics with host object, should be proactively addressed.

There are open bugs for Webkit[3] and Chrome[4] for implementing Array generics At the time that I filed the webkit bug, I was under the impression that it was on its way to being standardized. I do not see that happening.

Proposals:

  1. ES Harmony standardize Static Array and String generics
  2. The IE team use Native object for Host object collection

[0]proposals:static_generics [1]developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Working_with_Arrays#Working_with_Array-like_objects [2]esdiscuss/2009-May/009317 [3]bugs.webkit.org/show_bug.cgi?id=20261 [4]code.google.com/p/v8/issues/detail?id=308

# Maciej Stachowiak (15 years ago)

On Dec 4, 2009, at 1:48 PM, Garrett Smith wrote:

Static Array and String Generics was an ES4 proposal[0], and is implemented in Mozilla JavaScript 1.6[1].

What are the plans for including Array and String Generics in future revision of ES?

I'm curious about this as well. We've had some requests to add these
to JavaScriptCore. I'd like to know if they were explicitly rejected
from standard ECMAScript, or might be considered for further
ECMAScript editions.

Would the ECMAScript standards community advise that we implement
these in WebKit or hold off?

# Allen Wirfs-Brock (15 years ago)

The "static generic" versions of these functions were discussed during the development of ES5 but nobody advocated strongly for their inclusions.

My personal opinion is that having what appears to be duplicate functions on both Array and Array.prototype is a likely source of confusion for unsophisticated programmers and largely unnecessary for more sophisticated programmers who know how to use call.

The inadmissibly of the array functions for host object is explicitly allowed for by the ES3&5 specifications. However, I will make sure that those responsible for the IE DOM are aware of the issue.

# Mark S. Miller (15 years ago)

On Mon, Dec 7, 2009 at 11:40 AM, Maciej Stachowiak <mjs at apple.com> wrote:

On Dec 4, 2009, at 1:48 PM, Garrett Smith wrote:

Static Array and String Generics was an ES4 proposal[0], and is implemented in Mozilla JavaScript 1.6[1].

Note that the function generics on that page[0] break Liskov substitutability, since the Function constructor is itself a function inheriting from Function.prototype. Thus, Function.apply overrides Function.prototype.apply while implementing an incompatible contract.

What are the plans for including Array and String Generics in future revision of ES?

I'm curious about this as well. We've had some requests to add these to JavaScriptCore. I'd like to know if they were explicitly rejected from standard ECMAScript, or might be considered for further ECMAScript editions.

They were explicitly rejected for ES5, but more by way of postponing the issue rather than rejecting them for the future. They may indeed be considered for ES-Future.

Would the ECMAScript standards community advise that we implement these in WebKit or hold off?

I would recommend holding off. IMO, their extra convenience does not pay for the added complexity.

# Garrett Smith (15 years ago)

On Mon, Dec 7, 2009 at 2:50 PM, Mark S. Miller <erights at google.com> wrote:

On Mon, Dec 7, 2009 at 11:40 AM, Maciej Stachowiak <mjs at apple.com> wrote:

On Dec 4, 2009, at 1:48 PM, Garrett Smith wrote:

Static Array and String Generics was an ES4 proposal[0], and is implemented in Mozilla JavaScript 1.6[1].

Note that the function generics on that page[0] break Liskov substitutability,

Yes, the LSP issue with Function.apply was discussed..

The subject is about static Array and String generics, not Function Generics. Array generics alone would provide more benefit, so for sake of simplifying the argument, it might be best to narrow the focus to discussion of static Array generics.

What are the plans for including Array and String Generics in future revision of ES?

I'm curious about this as well. We've had some requests to add these to JavaScriptCore. I'd like to know if they were explicitly rejected from standard ECMAScript, or might be considered for further ECMAScript editions.

They were explicitly rejected for ES5, but more by way of postponing the issue rather than rejecting them for the future. They may indeed be considered for ES-Future.

Fixing Function.prototype.toString wording was also postponed. As has been discussed, that method is still broken by design in ES5. Probably a number of desirable things were left unfinished (the TG39 committee should know about these more than I do).

Would the ECMAScript standards community advise that we implement these in WebKit or hold off?

I would recommend holding off. IMO, their extra convenience does not pay for the added complexity.

I am failing to understand the complexity argument. Can you clarify?

AISI, Array.prototype.slice.call(x, start, end) ia arguably more complex with Array.slice(x, start, end); The generic version, if implemented correctly, would be more efficient.

The cumulative effect of Array generics should be slightly faster, slightly cleaner code, in many places: www.google.com/codesearch?q=Array.prototype.slice+lang%3Ajavascript&hl=en&btnG=Search+Code

There is a reason I mentioned the IE error in the thread about static Array generics.

Array generics (non static) would probably see a lot more use, were it not for MSIE and "JScript object expected".

Suppose IE changes so that array generics "work" with host object. There would be a trend towards using Array.prototype.slice.call( x, s, e) as old error-throwing IE becomes obsolete. In that case, static* Array generics would get more widespread use and so the static Array.slice would be wanted in more places.

Garrett

# Patrick Mueller (15 years ago)

Garrett notes:

Array and String generics are useful for non-array objects.

The underscore library, Google's closure library, and I'm sure others, also implement some of the "Array" methods for Objects, iterating over key/value pairs. I'd like to see this capability added as well. At which point, making these methods of Array makes less sense.

Perhaps a new global object, Collection, which could contain such static methods that worked on arrays and objects both. Which fix the problem of the "appears to be duplicate functions" on Array / Array.prototype.

On Dec 7, 2009, at 3:42 PM, Allen Wirfs-Brock wrote:

The "static generic" versions of these functions were discussed during the development of ES5 but nobody advocated strongly for their inclusions.

My personal opinion is that having what appears to be duplicate functions on both Array and Array.prototype is a likely source of confusion for unsophisticated programmers and largely unnecessary for more sophisticated programmers who know how to use call.

The inadmissibly of the array functions for host object is explicitly allowed for by the ES3&5 specifications. However, I will make sure that those responsible for the IE DOM are aware of the issue.

Allen

-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Maciej Stachowiak Sent: Monday, December 07, 2009 11:40 AM To: Garrett Smith Cc: public-script-coord at w3.org; es-discuss Subject: Re: Static Array and String Generics and Host Objects (ATTN IE Team)

On Dec 4, 2009, at 1:48 PM, Garrett Smith wrote:

Static Array and String Generics was an ES4 proposal[0], and is implemented in Mozilla JavaScript 1.6[1].

What are the plans for including Array and String Generics in future revision of ES?

I'm curious about this as well. We've had some requests to add these
to JavaScriptCore. I'd like to know if they were explicitly rejected
from standard ECMAScript, or might be considered for further
ECMAScript editions.

Would the ECMAScript standards community advise that we implement
these in WebKit or hold off?

  • Maciej

There is no new syntax needed to support this. Scripts today can be compatible by adding:-

if(!Array.slice) { Array.slice= function( arrayLike, start, end ) { return Array.prototype.slice.call( arrayLike, start||0, end||arrayLike.length); }; }

However, there is a remaining problem there: No guaranteed behavior with Host object and Errors in IE. Example: javascript:alert( [].slice.call( document.childNodes ) );

Error in IE8: "JScript Object Expected".

It would be best for IE to use Native object for Host objects. That way, unwanted surprises like the above error should be done away with.

Array and String generics are useful for non-array objects.

The outcome of [].slice.call() should be determinable. It is up to public-script coord to define what happens when a Host object is used in an Array.

Brendan's 7-month-old message[2] asking for IE to comment on Array generics with host object, should be proactively addressed.

There are open bugs for Webkit[3] and Chrome[4] for implementing Array generics At the time that I filed the webkit bug, I was under the impression that it was on its way to being standardized. I do not see that happening.

Proposals:

  1. ES Harmony standardize Static Array and String generics
  2. The IE team use Native object for Host object collection

[0]proposals:static_generics [1]developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Working_with_Arrays #Working_with_Array-like_objects [2]esdiscuss/2009-May/009317 [3]bugs.webkit.org/show_bug.cgi?id=20261 [4]code.google.com/p/v8/issues/detail?id=308

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

Patrick Mueller - muellerware.org

# Garrett Smith (15 years ago)

On Mon, Dec 7, 2009 at 12:42 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:

The "static generic" versions of these functions were discussed during the development of ES5 but nobody advocated strongly for their inclusions.

My personal opinion is that having what appears to be duplicate functions on both Array and Array.prototype is a likely source of confusion for unsophisticated programmers and largely unnecessary for more sophisticated programmers who know how to use call.

Static arrray generics are already implemented in Firefox. I have not any complaint about Array.slice being confusing.

But if you want to discuss personal opinions, mine is that "Unknown Error" is the source of confusion and frustration. That, and your top posting is doing damage to the discussion.

The inadmissibly of the array functions for host object is explicitly allowed for by the ES3&5 specifications. However, I will make sure that those responsible for the IE DOM are aware of the issue.

Yet still no response from the IE team here, or on the other thread linked were Brendan asked for the IE Team to comment.

Back to opinions, now. What is your opinion on using generic method with Host object? That's a very open ended question, so I'll explain a more specific scenario:

A generic method is used with a host object as the thisArg. Should the generic method perform the specified steps of the algorithm?

To be more specific, given anObject that supports [[Get]], [[HasProperty]], and has a length property, where a program can successfully executes the following code:

var x = anObject.length; var h = anObject.childNodes; var z = anObject["0"];

Then should the result of Array.prototype.slice.call( anObject ) be predictable?

Take a look at Array.prototype.slice and, given an object with properties "length=2", "0=object0", "1=object1", or, if JSON notiation is clearer:

var object0 = {}, object1 = {}, anObject = { "length" : 2, "0", object0, "1", object1 };

  • looking at Array.prototype.slice:-

  1. Let A be a new array created as if by the expression new Array().

  2. Call the [[Get]] method of this object with argument "length". // 2

  3. Call ToUint32(Result(2)). // 2

  4. Call ToInteger(start). // start is undefind - ToInteger = 0.

  5. If Result(4) is negative, use max((Result(3)+ Result(4)), 0); else use min(Result(4), Result(3)). // Result 4 is 0, so use Min(0, 2) = 0

  6. Let k be Result(5). // k = 0

  7. If end is undefined, use Result(3); else use ToInteger(end). // end is undefined, Result 3 is 2.

  8. If Result(7) is negative, use max((Result(3)+ Result(7)), 0); else use min(Result(7), Result(3)). // Min(2, 2) = 2.

  9. Let n be 0.

  10. If k is greater than or equal to Result(8), go to step 19. // K is 0 [...]

  11. Call ToString(k).

  12. If this object has a property named by Result(11), go to step 13; but if this object has no property named by Result(11), then go to step 16.

  13. Call ToString(n).

  14. Call the [[Get]] method of this object with argument Result(11).

// Get the "0" property from anObject - object0.

  1. Call the [[Put]] method of A with arguments Result(13) and Result(14).

// A["0"] = object0

  1. Increase k by 1.
  2. Increase n by 1.
  3. Go to step 10.

// Continue populating A with properties from the thisArg.

  1. Call the [[Put]] method of A with arguments "length" and n.
  2. Return A.

In your opinion, should the result be predictable, as such? An why or why not?

Garrett

# Garrett Smith (15 years ago)

On Thu, Dec 10, 2009 at 7:02 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

On Mon, Dec 7, 2009 at 12:42 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:

The "static generic" versions of these functions were discussed during the development of ES5 but nobody advocated strongly for their inclusions.

[sni[p

To be more specific, given anObject that supports [[Get]], [[HasProperty]], and has a length property, where a program can successfully executes the following code:

var x = anObject.length; var h = anObject.childNodes; var z = anObject["0"];

Edit: Should habve been: var x = anObject.length; var h = "0" in anObject; // [[HasProperty]] var z = anObject["0"];

# Garrett Smith (15 years ago)

On Thu, Dec 10, 2009 at 7:02 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

On Mon, Dec 7, 2009 at 12:42 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:

The "static generic" versions of these functions were discussed during the development of ES5 but nobody advocated strongly for their inclusions.

[snip]

Static arrray generics are already implemented in Firefox. I have not any complaint about Array.slice being confusing.

Edit: I have not heard any complaint about Array.slice being confusing.

Garrett

# Garrett Smith (15 years ago)

On Mon, Dec 7, 2009 at 11:40 AM, Maciej Stachowiak <mjs at apple.com> wrote:

On Dec 4, 2009, at 1:48 PM, Garrett Smith wrote:

Static Array and String Generics was an ES4 proposal[0], and is implemented in Mozilla JavaScript 1.6[1].

What are the plans for including Array and String Generics in future revision of ES?

I'm curious about this as well. We've had some requests to add these to JavaScriptCore. I'd like to know if they were explicitly rejected from standard ECMAScript, or might be considered for further ECMAScript editions.

Would the ECMAScript standards community advise that we implement these in WebKit or hold off?

Mozilla js engine is the only one that implements static Array generics that I know of.

If webkit implements Array generics, then they will likely become standard. You might consider posting a thread on c.l.js to get more feedback from javascript programmers about static Array generics.

You might also consider the arguments of Allen and weigh them against the other arguments (mine), and make a decision.

Allen believes they will be the source of confusion. Mark Miller believes the added complexity is not worth the convenience provided. My arguments are that they can make the code simpler and clearer.

Garrett

# Mark S. Miller (15 years ago)

On Wed, Dec 23, 2009 at 1:30 PM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:

On Mon, Dec 7, 2009 at 11:40 AM, Maciej Stachowiak <mjs at apple.com> wrote:

On Dec 4, 2009, at 1:48 PM, Garrett Smith wrote:

Static Array and String Generics was an ES4 proposal[0], and is implemented in Mozilla JavaScript 1.6[1].

What are the plans for including Array and String Generics in future revision of ES?

I'm curious about this as well. We've had some requests to add these to JavaScriptCore. I'd like to know if they were explicitly rejected from standard ECMAScript, or might be considered for further ECMAScript editions.

Would the ECMAScript standards community advise that we implement these in WebKit or hold off?

Mozilla js engine is the only one that implements static Array generics that I know of.

If webkit implements Array generics, then they will likely become standard. You might consider posting a thread on c.l.js to get more feedback from javascript programmers about static Array generics.

You might also consider the arguments of Allen and weigh them against the other arguments (mine), and make a decision.

Allen believes they will be the source of confusion. Mark Miller believes the added complexity is not worth the convenience provided. My arguments are that they can make the code simpler and clearer.

I should add that I am not strongly opposed to static generics, provided their semantics is exactly related to the corresponding non-static generic in the proposed manner in all cases, except omitted for Function as previously discussed. If this regularity is strictly adhered to, then the psychological added complexity is O(1) rather than O(number of generics). I am unaware of any desired irregularities, so I don't expect this to be a problem.