[Kde-bindings] first step of QT4 binding for Perl5

[Richard Dale]

On Wednesday 31 January 2007, Dongxu Ma wrote:
> > The current PerlQt 3.0 Smoke library is generated with a perl script
> > which can
> > also parse all the Qt 4.2.2 headers. It could certainly be better
> > written, and replacing it with another parser, such as your one might be
> > a good idea.
> > I would personally like to use the KDevelop C++ parser in the future for
> > generating bindings, and other people think that using the gcc xmldump
> > tool
> > is the best way to do it.
>
> I am not very familiar with KDevelop C++ parser.
> In my personal opinion, the best binding parsers should have:
> 1) the lowest maintainence effort, the changes appears in a source file
> could be
>     grouped into two categories, language-specific syntax and tool-specific
>     markup. Both C++ and gcc (or other compiler) are growing, introducing
>     new syntax and idea with the time being. While the fundamental change
> on
>
>     the tool-specific level is macro. that is the reason why even the
> KDevelop C++
>     parser needs to be taught on new macros.
>     The works done by a compiler parser is quite different from my point of
> view.
>     It needs to identify every detail of a source, which means it works
> until the
>     bottom level. While the information to make a binding is not so deep.
> The
>     differences of goal will lead to differences in both maintainence and
> patch.
>     That is why I assume we need a 'fuzzy' parser in this area.
Well the KDevelop parser isn't for a compiler, and it's requirements are 
similar to what you need for bindings generation. I think it handles macros 
quite well, and doesn't need to be 'taught' them. But if the code being 
parsed has '#ifdefs' in it, then it has to know what the values are in order 
to know whether to parse the code inside or not.

> 2) the best format of result. I have different thought on the production of
> such a
>     parser. What SMOKE products is programmatic data dictionary. That is
> fine
>     for immediate compile and link. There is no readability then. Although
>     currently I still have no clear sight, in order to apply new
> functionality,
>     for instance, as mentioned, the class inheritance info, it is
> neccessary to patch
>     the result of parser. That is the main reason I plan to take YAML as
> the result
>     format, for both human readability and manual patch.
Well the code generated for language bindings isn't usually readable, and I 
don't think it requires to be readable either. What Smoke gives you is 
introspection so that you can query to api dynamically. For instance, if I 
want to know whether an 'objectName' method is present I can use a command 
line tool 'rbqtapi' to find out:

mardigras rdale 672% rbqtapi -robjectName
        QString QObject::objectName() const

Which is very similar to the way you can use runtime introspection in Qt for 
QObjects to find out what slots a class has via the QMetaObject system.

> The parsing is only a small part of a bindings project, and by far the
>
> > hardest
> > bit is deciding what code to generate. I think the way the Smoke library
> > works is very hard to beat, as it is the only library for language
> > bindings
> > that can work with more than one language (ie perl, ruby, c# and php
> > currently). So I'm more interested in helping to design a better version
> > of
> > Smoke, which perhaps would use some of the way the Qt 4 moc generated
> > code works, but allowing for multiple inheritance and generating code for
> > every method in every class and not just slots in QObject subclasses.
>
> sure, that is main reason I  dropped such post here. You guys have rich
> experience
> on both QT and interface design. I do need to learn new ideas from you all
> ;-)
>
> -- Richard
>
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 30 Jan 2007 15:52:01 +0100 (MET)
> > From: Arno Rehn <arno at arnorehn.de>
> > Subject: Re: [Kde-bindings] first step of QT4 binding for Perl5
> > To: KDE bindings for other programming languages
> >         <kde-bindings at kde.org>
> > Message-ID: <200701301552.00096.arno at arnorehn.de>
> > Content-Type: text/plain;  charset="iso-8859-1"
> >
> >
> > I've recently talked to a Mono SWF developer and he suggested to generate
> > bindings with SWIG ( http://www.swig.org/ ). I've only taken a quick
> > glance
> > at it, but from what I've seen it could be useful. Maybe this could be an
> > alternative to the SMOKE library, even though I don't know how to handle
> > signal/slots or marshalling with SWIG.
> > At the moment I'm very satisfied with SMOKE :-)
>
> SWIG is quite nice on making generic bindings, but as I said, just generic
> ones.
>  For different dynamic language, what should be considered is, how to best
> fit
> the popular program semantics/pratice introduced by that language. For
> instance, in Perl, people will perfer operate on tied magical variable
> rather than
> raw data container. There are language specific part that swig could not
> handle
> properly at this moment. One of the main reasons why people choose binding
> instead of original c library is definitely here. Well, I indeed saw
> something nice
> made by swig on CPAN ;-)
I tried to use SWIG to generate Ruby bindings for Qt in early 2002, and at 
that time I  would describe it as pretty poor and that attempt at a Ruby 
binding failed. The 'S' in SWIG stands for 'simple', and wrapping the Qt 
library is by no means simple. I've found that the Smoke approach works much 
better for both the QtRuby and Qyoto C# projects, and not having to do 
different code generation for every language makes writing bindings easier.

-- Richard