Planning JavaScript 1.9

Posted: April 16th, 2008

23 Comments (Show Comments)

1. Morgan 'ARR!' Allen (April 16, 2008 at 2:52 pm)

   The bind will be so nice to finally have. But I recall reading (I cannot find where), that Firefox would not be including JSON support to the Javascript engine. That it will only be available in chrome. Is this incorrect?

2. John Resig (April 16, 2008 at 3:02 pm)

   @Morgan: In Firefox 3 it will only be available to extensions, correct. It’s, pretty-much, a shoe-in for the next release.

3. Scott Johnson (April 16, 2008 at 3:13 pm)

   I’m with you on the JSON. Native JSON encoding/decoding would be HUGE!

4. Bertrand (April 16, 2008 at 3:39 pm)

   Why still no support for date literals (forgive me if that’s in and I somehow missed it)?

5. John Resig (April 16, 2008 at 4:18 pm)

   @Bertrand: Good question – I’m not sure exactly (I became more informed after reading your post on the subject). I don’t know if this has been brought up, before, in the ECMA working group (I can’t seem to find a reference to it, if it has). I’ll pass it along, but I’m honestly not sure what to expect at this point in the process. Do you know if this has been brought to the attention of the Microsoft representative who’s in ECMA?

6. Bertrand (April 16, 2008 at 4:25 pm)

   Thanks for the answer, John, and thanks for passing it along. No, I don’t think our representative at ECMA has been passed that information. I can try to do that but as you may suspect, I’m speaking here with my group’s own interests in mind, which are not necessarily aligned with the company’s position as a whole. If you see what I mean. Which you do. :) Anyways. Feel free to ping me on e-mail if you want to continue that conversation without boring your other readers to death ;)

7. Peter Michaux (April 16, 2008 at 6:57 pm)

   I proposed Function.prototype.bind() and at least Brendan Eich seemed to like it. It is also in the ECMAScript wiki at the bottom of the generic function page, I believe. The only library I found that has something different than the Prototype library is Dojo. In Dojo it is possible to rebind an already bound function to a new object. I think that is a bad idea. When it is bound it should be bound for good. After all a method called “bind” sound quite permanent.

   Another issue is should bind take paramaters like Function.prototype.apply or like Function.prototype.call? The apply version is easier to use in some cases.

   —–

   Wasn’t native JSON already part of and then removed from the ES4 spec?

8. John Resig (April 16, 2008 at 8:18 pm)

   @Peter: Function.prototype.bind has already been specified and recently went through its last call for feedback. The method signature is specified as:

   intrinsic function bind(thisObj: Object, ...args)

   Which is equivalent to Function.prototype.call() (specifying the arguments in order). This works just fine since in ECMAScript 4 you have the splat operator which allows you to auto-expand arrays out, filling up the arguments. Meaning that the following will work:

   var someArray = [0,1,2,3,4];
someFunction.call(obj, ...someArray);

   A global JSON object hasn’t been accepted by any implementer of the specification, thus far – but that won’t stop implementers from creating their own. Mozilla’s will probably be something like mozilla.JSON.decode and mozilla.JSON.encode. Having an implementation in place, in a browser, would be far too useful to web developers.

9. Mike Shaver (April 16, 2008 at 8:35 pm)

   Native JSON was left to libraries rather than language definition as far as ES4 goes, but we have it in Firefox for extensions and app code, and it works great (and hauls ass). We just didn’t want to rush security analysis in the end game before exposing it to content, so it got held over.

   (The main guy behind native JSON, Rob Sayre, was also busy quarterbacking our huge JS performance gains that landed for beta 4. I hope you’re not too disappointed with the trade. :) )

10. kangax (April 16, 2008 at 9:48 pm)

    How about some querySelector love?

11. John Resig (April 16, 2008 at 10:00 pm)

    @kangax: Oh sure – definitely expect that – although that’s not really part of the JavaScript language (DOM stuff).

12. kangax (April 16, 2008 at 11:18 pm)

    Well, as far as language improvements – any of Crockford’s proposals [1] would make life much easier. From least “aggressive” changes – String#trim, and “proper” typeof would probably make most sense.

    [1] http://javascript.crockford.com/recommend.html

13. John-David Dalton (April 16, 2008 at 11:23 pm)

    The ability to set the enum flag of a property.
    So they would not be seen in for-in loops and the like.
    http://www.dhtmlkitchen.com/learn/js/enumeration/dontenum.jsp
    “setPropertyIsEnumerable”

14. John-David Dalton (April 16, 2008 at 11:27 pm)

    Actionscript used to have an equiv too: http://www.devarticles.com/c/a/Flash/Undocumented-ActionScript-Flash-Hack/

15. John Resig (April 17, 2008 at 7:31 am)

    @kangax: String.prototype.trim is pretty much a shoe-in. typeof stuff is trickier, since that might break existing web sites.

    @John-David: setPropertyIsEnumerable is defintitely possible.

16. John-David Dalton (April 17, 2008 at 9:38 am)

    How about some form of compression support via strings.
    http://www.strille.net/tutorials/FlashXMLCompressor/index.php

    I have done some LZ77 compression in strings and its helped with storing extra cookie data (the compression is a bit slow, but works well, native support could speed that up.

    myLongDataOrJSONString.compress();

17. John Resig (April 17, 2008 at 9:57 pm)

    To those curious: The meeting went well today, we have the feature list hashed out fairly well – we’re finishing up pairing it down, where we can, and will have a full public list soon – keep watching!

18. AndersH (April 18, 2008 at 9:12 am)

    Are there any chance, we could get c-style variable declarations and casts (i.e. “TypeName varName = (TypeName)foo”, with the keyword “var” changed to behave like “auto” in c++ and “var” in c# such that “var varName = foo” would infer the type for “varName” from “foo”), instead of pascal(/actionscript, I guess)-style (i.e. “var varName:TypeName = TypeName(foo)”)?

19. Sebastian Deutsch (April 20, 2008 at 6:36 pm)

    A bind function would be awesome.

20. Toland (April 21, 2008 at 1:30 pm)

    hey john wish i hadn’t been late on this bandwagon. i’m just now learning as3 which has been really enlightening on the direction for js2. reading a couple outlines for es4 i have a short wishlist:

    1. conspicuous omission of constructor access modifiers and enum types from ecma-262. i saw these mentioned in the es4 wiki and wondered which made the cut.

    2. the other would be an interceptor/sequence syntax. although Function#intercept and Function#sequence might be handy rather i would find the following syntax quite useful:

    class subcls extends supcls {
intercept method1() {/*add'l code*/}
sequence method2() {/*add'l code*/}
}

    in lieu of:

    class subcls extends supcls {
override method1() {
super.method1();
//add'l code
}
override method2() {
//add'l code
super.method2();
}
}

    one benefit is simply conciseness but another would prevent accidentally calling method1 from method2 incurred by a copy/paste oversight that the compiler couldn’t resolve. i know it’s late in the game but apart from lacking these reserved words the implementation would be seemingly straightforward. a debugger warning would be half as good of course.

21. Toland (April 21, 2008 at 2:05 pm)

    my bad obviously left out the function keyword a few times:
    class subcls extends supcls {
intercept function method1() {/*add'l code*/}
sequence function method2() {/*add'l code*/}
}
    in lieu of:
    class subcls extends supcls {
override function method1() {
super.method1();
//add'l code
}
override function method2() {
//add'l code
super.method2();
}
}

22. Kris Zyp (April 22, 2008 at 10:48 pm)

    I would love too see Mozilla expose their coroutine capabilities: https://bugzilla.mozilla.org/show_bug.cgi?id=425988
    http://www.openajax.org/runtime/wiki/JavaScript_Pause_Release
    they already did the hard work:
    https://bugzilla.mozilla.org/show_bug.cgi?id=403535

23. Cyrus Omar (May 5, 2008 at 9:26 pm)

    I second setPropertyIsEnumerable and top level yield.

    I would also like to see the beginnings of catchall getter/setters like JS2 will have, maybe with the following API:

    
obj.__defineGetter__(function(idx) wrapped[idx])
obj.__defineSetter__(function(idx, value) wrapped[idx] = value)


    This would allow for some interesting things like lazy, sparse arrays and allowing the full use of generators in libraries which still loop by index. You could also, e.g., create a shared object between a client and a server that can be passed around to code that doesn’t know its shared:

    
obj.__defineSetter__(function(idx, value) sendToServer(this.name, idx, value))


Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.