e4x and dom support in gecko 1.9

[Irfan Mohammed]

Hi,
I have a xul application and using the latest xulrunner from the
trunk. Should the transparent integration between e4x and dom work?

I tried

var edom = new XML(document);

and it fails.

Is there a recommended workaround?

Thanks,
Irfan

[Martin Honnen]

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 tried
>
> var edom = new XML(document);
>
> and it fails.

This bug <https://bugzilla.mozilla.org/show_bug.cgi?id=270553> is about
the integration but there has not been any progress there for a long time.

--

Martin Honnen
http://JavaScript.FAQTs.com/

[bre...@mozilla.org]

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 tried
>
> > var edom = new XML(document);
>
> > and it fails.
>
> This bug <https://bugzilla.mozilla.org/show_bug.cgi?id=270553> is about
> the integration but there has not been any progress there for a long time.

I'm not planning to work on this any time soon; therefore I really
should assign it to gen...@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.

/be

[Jeff Walden]

bre...@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?

> js> var x = <foo/>;
> js> x.bar = "baz";
> baz
> js> x.toXMLString();
> <foo>
> <bar>baz</bar>
> </foo>

Worse, this applies at more depth, so you can assign to "non-existent" spots in the XML tree:

> js> x.a.b.c.d = 3
> 3
> js> x
> <foo>
> <bar>baz</bar>
> <a>
> <b>
> <c>
> <d>3</d>
> </c>
> </b>
> </a>
> </foo>

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

[Irfan Mohammed]

On Jul 16, 10:30 pm, Jeff Walden <jwalden+...@mit.edu> wrote:

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.