On 15/01/2008, Keryx Web <[EMAIL PROTECTED]> wrote: > "I know Opera have E4X in the works at some level" > http://www.codingforums.com/showpost.php?s=a9dfc400dfd427203a99487bd4ea29d9&p=448007&postcount=10
That comment's based on the the fact that Opera resolved my RFE for "for each" looping as fixed, and "for each" is part of E4X. It's a very long step to derive the assumption Opera have E4X in the works from that, however. There's tons of uses of "for each" looping, and implementing "for each" is cheap if you're aiming at creating an internal structure that will be able to implement ES4 enumerators efficiently. > My questions: > 1. Are there any clear indications from the developers of these browser > engines (or their internal ECMAScript engines) that I've missed? Well, you might want to read what Jeff Walden says about Mozilla implementing E4X at <uri:http://www.webstandards.org/2008/01/16/whats-the-best-test-for-acid3/#comment-59499> > 2. Will E4X on MSIE in fact be facilitated through ScreamingMonkey? > > 3. When do you predict that we can really start using E4X and expect it > to work for most visitors to our websites? With any luck, it will be E5X (well, it's a better name than E44X...) by then, will work well together with ES4, and have several integrity and interoperability problems fixed. On 15/01/2008, David Storey <[EMAIL PROTECTED]> wrote: > I can't comment officially on support for ECMAScript 4, but we do > have people that are involved in the ECMAScript meetings (such as at > http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jul_27_2006), > and we do strongly believe in implementing standards. We also have > an article on Dev Opera from our lead javascript engineer on why he > loves ECMAScript4 - http://dev.opera.com/articles/view/why-i-love- > ecmascript-4-real-decimals/ . So you can take those as hints that we > plan support sometime in the future. E4X is not part of ECMAScript 4, it's an extension to ECMAScript 3. A slightly broken one, at that. To quote myself in a mail to one of the Opera volunteer mailing lists, editing out the quoted Opera staff: > If you ask me (which you haven't...): > > - E4X isn't that very useful unless it cooperates seamlessly with the > DOM, so that we can use it to manipulate document trees in place. This > is not the case in the Moz implementation, and that level of E4X is > simply not worth it for developers. > > - ES4 though - I can imagine a few of the new features being popular, > but them being relevant for developers would require pretty much all > browsers to have implementing them as a high priority issue. I'm > particularly interested in features like true arrays, true > dictionaries, the new number types and the scope improvements from > block scope and namespaces. > > - Most interesting for a developer is those changes that can be > emulated if not present, that doesn't need a "use only if this support > is present" switch like a version=#.# attribute on the Content-Type - > that is, mostly standard library stuff. This simply because those can > be utilised in current code with only minor headaches, unlike any of > the syntax additions. I'd say Opera would do best spending developer resources: 1a. Matching the syntax/semantics extensions of Mozilla JavaScript 1.6-1.9, with array comprehensions, let blocks, let expressions etc. 1b. Implementing standard library only fearures. (.hashcode property on all values is an example I'd like to see here) 2. Implementing the features of ES4 in order of what is perceived to give most benefit to web developers with some kind of opt-in flag รก la "application/javascript;e4x=1". 3. And maybe last, E4X. -- David "liorean" Andersson ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
