Lambda the Ultimate

As you can see, it's not surprising that BEA supports it as seems that it's BEA that instigated it. If you recall the XML programming discussion, you will see that Tim Bray links to an article by Adam Bosworth Vice President of Engineering at BEA in hints at this development.

Indeed, I can add several new concerns:

1. Various partial workarounds (hacks) to handle scenarios where XML node names conflict with reserved words or member functions.

2. Changing the semantics of the for...in statements - for standard ECMAScript objects it iterates over the indices, for XML it iterates over the values.

3. Lots of new operators and new ways to bunch operators together.

4. Yet another overload for {...} (ECMAScript already uses it for 2 distinct purposes).

5. += and + used to combine XML, but delete and not - or -= is used to remove elements.

As I stated in the past, I like seeing ECMAScript extended with new functionality. OTOH such additions should be done in a way that is consistent with the feel of the language. IMO BEA (like Microsoft with JScript.NET before them) have crossed that line a bit.

I'm not sure what you mean by serious. If you mean changes to ECMAScript that would have made XML programming as simple, then I think it's a bit of a loaded question. Once such changes are introduced into the language they affect everything, not just XML programming. So if a change makes XML handling easier but has the downside of making the language specification more fragile, is that a good thing? E4X was intentially not done as a library so you can't just take it or leave it. Being a language extension you must always take it, whether or not you intend to use it.

Actually I'm not quit sure about that. It could be that you will have some sort of compiler switch to activate the E4X extensions. If that is the case then (like JScript.NET /fast switch) I'm not sure the cure isn't worse than the disease.

Other objections I have are fixable IMO. They have made some design decisions, that while logical in themselves, create unwarranted distinctions between standard ECMAScript objects and XML objects. For example, the implementation of for...in and support for the .. operator. As a result, identical code will behave differently if an XML object is passed as parameter or any other type of object.

I also think ECMA could have provided language extensions which would have allowed application of some of these features in other contexts. Want to support += for adding items to an XML list? fine, but allow me to use += for my lists as well, i.e. operator overloading. Currently ECMAScript doesn't even support += on intrinsic arrays.

Finally, adding lots of operators makes expressions shorter, which certainly makes it look cooler during a demo. But in the long term, I'm not a big fan of Perl-style syntax. I prefer to have to write a bit more and make code more readable.

Oh yes, one other thing. They totally ignored ECMAScript's functional capabilities. Even when they made perfect sense, such as filtering with Predicates.

That's basically what I wanted to ask. Were such extensions suggested and discussed?