Subj : Re: E4X support in mozilla? To : Shanti Rao From : Brendan Eich Date : Mon Jan 03 2005 02:07 pm Shanti Rao wrote: > > Ain't broke, don't fix. It's not hard to write a fault-tolerant XML > parser in JS, and how do I know that the choices made in designing E4X > are going to be the ones I desire or expect? E4X folks designed (and hacked, a lot -- one prototype based on Rhino predates the standard, woohoo!) with XQuery and other XML standards in mind. They separated data model from syntax, and built on xml-infoset (errata notwithstanding; the spec's being fixed for ISO). > See earlier discussion > about JS2.0 for inherent reticence to embrace changes to languages that > underpin complex systems. That's a bit to general to work with. :-/ > E4X appears to take a vocabulary (E) and force it onto an object model > (X). I would have been a lot happier if the designers had started with a > clear data processing objective, and invented a vocabulary to match. I'm pretty sure they did that, but I wasn't around, so I'll defer to others who may know better. > What we have now looks a lot like a camel. Camels are useful, even if Ugly. You know you're dangerously close to insulting Perl here... ;-) > Consider some sample code from > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-357.pdf > > var twoemployees = e.employee.(@id == 0 || @id == 1); > for each (var p in e..employee) { ... } > > What's this @ stuff? Attributes are in a separate namespace with a distinct operator prefixing literal name uses. This is based directly on XQuery, IIRC. > Perl is the language of obscure punctuation, You're now over the edge. Look, @attrname is not obscure, and if you don't like at-signs, think of them as "at"tribute signs. JS+E4X is not Perl by a long shot, but I'm not about to join you in knocking Perl. And I don't mean Perl 6, either, I mean Perl 5, hack that it is. Hacks can be useful. > I just know that some newbie is going to look at that and > think that they can get away with that sort of syntax for any JS object, > then call me and wonder why it doesn't work. They'll get a clear diagnostic. You can't write 42() in JS and have it evaluate to 42, either -- why aren't newbies confused by that? Newbies don't just throw in @ because it looks cool (or you have a lower grade of newbie than you should tolerate). > Then they'll ask how many > dots are supposed to be between e and employee. And I won't have a clue? .... is used in C-like languages, but maybe three times is the charm. > I wish that the E4X designers had put compactness of syntax secondary to > clarity of purpose. In a few places, I agree with you, but JS already loses to Python (never mind Perl) in the estimation of people I respect because of JS's C/Java verbosity, both for block structure and control keywords, and in the lower-level sub-grammars. And Python is winning while we all wait for Perl 6. So there has to be a fine balance between conciseness and readability, and I think E4X gets it mostly right. > There have been enough changes since 1.5rc6a that you might consider a > new version number. The ATLINE option is new, and XML hooks are pervasive. JSOPTION_ATLINE is a tiny API option for XUL preprocessing, it hardly merits a version trip. The XML hooks are indeed pervasive, but that's an implementation detail. The language doesn't change unless you both compile-time enable *and* run-time enable E4X. The version number is for the language, not for the implementation. > I'm reading through jsxml.c, and notice that you sensibly observe that > > escaping isn't necessary. Can you explain the testcase What testcase? > It will be interesting to figure out how namespaces work. Do namespaces > go into the global string hash table? What global string hash table? I think you are mixing up implementation details, but if you have a language question about namespaces, I can help. E4X namespaces are being made consistent with namespaces in Edition 4 (JS2, ActionScript 2). /be .