Irfan Mohammed wrote: > I have a xul application and using the latest xulrunner from the > trunk. Should the transparent integration between e4x and dom work?
On Jul 13, 7:08 am, Martin Honnen <mahotr...@yahoo.de> wrote:
> Irfan Mohammed wrote: > > I have a xul application and using the latest xulrunner from the > > trunk. Should the transparent integration between e4x and dom work?
I'm not planning to work on this any time soon; therefore I really should assign it to gene...@js.bugs and let someone else take it.
I have a jaundiced view of E4X after having waded through spec and implementation. It is superficially appealing, and there is good in it, but the whole is less than the sum of parts, and a few crucial design decisions (such as making methods not be properties, and the wannabe-perlish magic singleton-list-looks-like-element-looks-like- String hacks) often backfire big-time. The DOM integration looks to me like a big bloat and security bug attack surface right now.
I do have some thoughts on how to implement E4X<->DOM bridging in the context of Gecko's current DOM, if anyone is interested. I'll try to write them down in a coherent form.
People seem to be making do with serialization and deserialization when using E4X and the DOM (which one? Probably in fact the HTML DOM). True? Sort of like JSON.
A more systematic approach to filtering, collections, attributes, and language-integrated query would be better. In the context of JS2/ES4, I've joking called this "E5X", but it's just pie-in-the-sky for after Edition 4 is done. ES4 currently merely reserves ECMA-357 syntax (lexical and main grammar) but does not require E4X.
David Caldwell, Jeff Walden: feel free to chime in.
bren...@mozilla.org wrote: > I have a jaundiced view of E4X after having waded through spec and > implementation. It is superficially appealing, and there is good in > it, but the whole is less than the sum of parts, and a few crucial > design decisions (such as making methods not be properties, and the > wannabe-perlish magic singleton-list-looks-like-element-looks-like- > String hacks) often backfire big-time. The DOM integration looks to me > like a big bloat and security bug attack surface right now.
Yeah, that about sums it up. The spec is poorly thought out. The most important pieces of it, [[Get]] and [[Put]] on XML and XMLList, are extremely dense and nearly impossible to rigorously reason about, and the numerous specification bugs encountered during implementation (some of which have been fixed in the second edition of ECMA-354, some of which still remain) and subsequent testing demonstrate that they are too complex to be usable or to prove important correctness properties, such as "no XML item ever is the child of two different XML items" or "no XML 'tree' contains a cycle" or "the string representation of any XML item is itself valid XML". The spec was simply not formulated in a manner which would make it relatively easy to prove these properties, and they're a fundamental part of XML or a system designed around it. In a memory-safe language like Java this is a problem in that methods assumed to be infallible no longer are, and uncaught exceptions will terminat e the program. In an unsafe language like C, in which SpiderMonkey is implemented, this leads to null dereferences, out-of-bounds accesses, type errors due to C's required casting, and other manners of security bugs, not to mention just the general goofs and unexpected results that occur as the result of these problems.
The design problems Brendan mentions also come into play here. There are a lot of nice things in E4X, and if you use it at a superficial level it may work reasonably well, well enough that you don't hit its nasty edges, of which I'll list a few here. For example, if you have an XML element and you assign to a property on it which is a name naming no XML elements within that element, an element of that name is "magically" created to contain whatever you assigned. Was this what you intended? Maybe, maybe not, but could you have guessed that would be the result?
Note further that this means that the following invariant of JavaScript prior to E4X no longer holds:
> prop in obj === false > => > obj[prop][prop2] = value will result in a TypeError
There are lots of quirks like this that you may not run into for small things, but if you tried to do anything interesting with E4X, you'd quickly run into pain like this. E4X tries to mesh with existing JS guarantees, but it doesn't work correctly much more often than I'd like.
I think it is possible to formulate a "good" version of E4X, one in which it is possible to prove some of the properties I mention exist, one where much of the JS/XML-inspired surface syntax is present and useful. I do not believe it can be done on the back of what E4X has already accomplished; there are too many fundamental problems in E4X for using it as a base to be workable.
> bren...@mozilla.org wrote: > > I have a jaundiced view of E4X after having waded through spec and > > implementation. It is superficially appealing, and there is good in > > it, but the whole is less than the sum of parts, and a few crucial > > design decisions (such as making methods not be properties, and the > > wannabe-perlish magic singleton-list-looks-like-element-looks-like- > > String hacks) often backfire big-time. The DOM integration looks to me > > like a big bloat and security bug attack surface right now.
> Yeah, that about sums it up. The spec is poorly thought out. The most important pieces of it, [[Get]] and [[Put]] on XML and XMLList, are extremely dense and nearly impossible to rigorously reason about, and the numerous specification bugs encountered during implementation (some of which have been fixed in the second edition of ECMA-354, some of which still remain) and subsequent testing demonstrate that they are too complex to be usable or to prove important correctness properties, such as "no XML item ever is the child of two different XML items" or "no XML 'tree' contains a cycle" or "the string representation of any XML item is itself valid XML". The spec was simply not formulated in a manner which would make it relatively easy to prove these properties, and they're a fundamental part of XML or a system designed around it. In a memory-safe language like Java this is a problem in that methods assumed to be infallible no longer are, and uncaught exceptions will terminat > e the program. In an unsafe language like C, in which SpiderMonkey is implemented, this leads to null dereferences, out-of-bounds accesses, type errors due to C's required casting, and other manners of security bugs, not to mention just the general goofs and unexpected results that occur as the result of these problems.
> The design problems Brendan mentions also come into play here. There are a lot of nice things in E4X, and if you use it at a superficial level it may work reasonably well, well enough that you don't hit its nasty edges, of which I'll list a few here. For example, if you have an XML element and you assign to a property on it which is a name naming no XML elements within that element, an element of that name is "magically" created to contain whatever you assigned. Was this what you intended? Maybe, maybe not, but could you have guessed that would be the result?
> Note further that this means that the following invariant of JavaScript prior to E4X no longer holds:
> > prop in obj === false > > => > > obj[prop][prop2] = value will result in a TypeError
> There are lots of quirks like this that you may not run into for small things, but if you tried to do anything interesting with E4X, you'd quickly run into pain like this. E4X tries to mesh with existing JS guarantees, but it doesn't work correctly much more often than I'd like.
> I think it is possible to formulate a "good" version of E4X, one in which it is possible to prove some of the properties I mention exist, one where much of the JS/XML-inspired surface syntax is present and useful. I do not believe it can be done on the back of what E4X has already accomplished; there are too many fundamental problems in E4X for using it as a base to be workable.
> Jeff
Thanks for the update.
For now, I am just serializing the dom document as a string and then de-serializing as an e4x document and using it. If there is a better/ scalable approach, please let me know.
