In designing an initial implementation of XPathGenerator, I decided I'd try first to implement it as a JavaScript-based component with a few special-case C++ functions included. The idea was to make it more generic than normal, so that converting from one language to another would be somewhat easier on my soul. The code wouldn't have been review-ready at first, but if I could make it work in JS, it'd be relatively simple to drop the less-than-relevant portions.
There's some wisdom to that approach now, it seems. This evening, I hit upon a new situation entirely. In executing alert(typeof JSXPathGenerator) (a test name for the component's implemented XPathGenerator constructor), I got something I'd never seen before: a QueryInterface call with an IID that isn't in Components.interfaces.
A little quick research and a modified dump() statement led to nsIDOMCIExtension. This defines a fair number of little macros that don't make any sense at all until you look at the XML Extras module & factory code. Even then, it makes very little sense to me.
So, in other words, after all my initial work, it appears there's no easy way to create a JS-based XPCOM component to deliver a constructor. Now, if someone would translate nsIDOMCIExtension's macros into something more cross-language friendly, I wouldn't have this problem. Or if there was a JS equivalent (I'm not in the mood to do the translation), I could keep going.
But back to the original topic. I'm trying to decide whether to pursue this in JavaScript or C++.
WeirdAl bz: let me rephrase. I'm trying to find the path of least resistance to implementing this thing. WeirdAl if that path is C++, then so be it. bz_sleep finds all paths involving creating new components to have high resistance. ;)
So, at least for the moment, I'm in a pit. I'll be starting over from C++ fairly soon, unless someone's nice enough to figure out the nsIDOMCIExtension code and write some new code to support me there. At least the JS code gives me a partial mock-up to follow.
Overall, unlike my previous blog entry, I find this amusing.
Oh, one more thing: the typeof call, because of the XPCOM error, didn't pop up any dialog at all, not even "undefined". I have filed as bug 325707.
UPDATE: Thanks to peterv, timeless, and #developers, I've got a C++-based constructor component built. It doesn't do anything yet, but you can construct objects from it. Reference bug 319768, comment 21 for the patch.
Posted by WeirdAl at February 3, 2006 12:09 AMHmm, where's the idl? I've got a couple js xpcom components in komodo and dont run into problems with them, I'd be willing to give the code a spin.
(From Alex: http://wiki.mozilla.org/DOM:XPath_Generator . Be advised, though, that it's still in flux -- I updated it yesterday -- but generally I won't change it without having myself and another person agree on it.)
Posted by: Shane Caraveo at February 3, 2006 10:18 AMOk, modified code at http://mozilla.pastebin.com/537741
I tested under 1.8 branch.
your fn.apply calls were incorrect, and some of the exception stuff you're doing doesn't work. I now get a "kind of" working xpath generator.
btw, my current generator is at http://mozilla.pastebin.com/537746
I've hacked a way to deal with anonymous nodes for now.
Hm, is it just me or the code at http://mozilla.pastebin.com/537741 (suggested by Shane) doesn't work either (in the sense that trying to do something with JSXPathGenerator tries to do the same QI)? I'm testing with a trunk build, but I don't suppose it matters.
(From Alex: The code is highly non-functional. :-) It's going to take me some time, that's all.)
Posted by: Nickolay Ponomarev at February 4, 2006 12:12 PM