[Kde-bindings] XPath is my friend

[Ashley Winters]

--- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:

> I've been reading Ashley's latest blog:
> http://jahqueel.blogspot.com/2005/06/bindings-xpath-is-my-friend.html
> 
> The idea of breaking down the library into one .so file per class and
> loading 
> on demand sounds interesting. I'm not sure about keeping the xml as
> text 
> inside the .so file, and then adding it to the DOM at runtime. It
> seems a bit 
> wasteful having it take up memory when it's no longer needed -
> wouldn't it be 
> better to have the xml as text files seperate from the .so libs?

It's still needed, though. It replaces the smoke datastructo which
lists methods/arguments/function-numbers. It replaces the foo$$$
mangling. Stuff like that.

Instead of coming up with a foo$$$ mangled method name based on the
arguments passed in, you generate an XPath. Like my example from the
blog, we replace:

foo$$$

with:

//method[@name='QSomething::foo' and (param/last() = 3 or
param[4]/default)]

I don't expect generating the XPath string would be anymore difficult
than generating the $$$ string, The XPath query returns a list of all
the methods which match the query. If there's more than one, you
execute another XPath to narrow it down, or you loop through them to
find the closest match. Whatever works best.

> How will the C# bindings work - are you intending to divert all the
> calls 
> through Proxy.Invoke() like I was going to do when I last tried? Or
> if you 
> were going to do something more conventional, where each C# method
> calls the 
> corresponding C++ method. There doesn't seem to be the need to use
> Smoke 
> introspection, and mainly it would just need virtual method callbacks

Depends on what you mean by introspection. Here's a C# function:

    void setName(string name) {
        my_proxy.Invoke(SMOKE_ID_OF_setName, name);
    }

How does the proxy know whether to serialize the 'name' parameter to a
QString, a QCString, or a const char*? Either the proxy.invoke needs to
have that information.

    [SmokeCoercion(Signature = "...")]    // via attribute?
    // passed to Invoke?
    my_proxy.Invoke(ID, "const QString&", name);

or it can use the id to grab the XML node efficiently and lookup the
coercions that way. Either way is fine. They need benchmarking, though.

> presumably via the new scheme using slots/signals.
> 
> "I expect to create an XSL stylesheet for the C++/moc4 Smoke binding,
> another 
> one for the O'Caml binding, and yet another one for the C# binding."
> 
> Does the XSL stylesheet for C# just generate C# code, which in turn
> uses the 
> C++/moc4 Smoke bindings? Or does it generate both C# and C++ code?

The former. The stylesheet just generates all the Proxy.Invoke calls.
And the O'Caml binding does the same, but differently.

> The disadvantage of having three different libs is that if we have a
> kde 
> plugin api, and write some plugins in O'Caml, some in C# and some in
> ruby 
> there will be three libs loaded taking up more memory than if there
> was a 
> single runtime Smoke lib for all languages.

No, I don't want to burden the language-bindings like that.

One Smoke to bring them all and in the Qt bind them. In the land of C++
where the KDE lie.

Ashley Winters

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com