Re: ruby-qt3 proposal (c++ based extensions)

Martin Man wrote:
> hi all,
> 
> I've prepared a short proposal on how to quickly (but without loosing
> features) create qt3 extension module for ruby, ..., if you are interested
> please read on and comment. This proposal came from the fact that we have
> actually gcc-xml output of all qt3 headers that can be reused somehow...
> 
> note that such proposal does not include any talk about signals and slots,
> these have to come yet, but it hopefully covers the c++ overloading problem..
> 
>

I proposed a similar solution already. Please refer the last thread on qt.
I could imagine some improvement to your solution:

For each qt class with virtual functions an overridable and not overridable version.
This would improve performance in the very commmon case, when you know that you
don't want to reimplement any virtual functions.

For the overridable class, I would create a function pointer table (playing the
same role as the virtual function pointer table.), having the pointer to the
original virtual methods. If a new method on the ruby-side is defined, then
it could change the pointer in this new method table. This, again, would
improrve runtime. The drawback would be that the handling of
singleton methods can get quite complicated, if not impossible. This no tragedy,
but it must be documented then. (Using this strategy, the first proposal may
get unnecessary.)

Some weeks ago, I created the XML files for qt3 using xmlgcc. This was fairly
straightforward. I also created a small Ruby programm using REXML, that parses the
generated representation and builds an internal representation which could be
used to generate the wrapper.

I planned to write a complete wrapper using this implementation, since the SWIG
has some annoying features including the strangeness for the .new methods.

Additionally, I would like to see a more intuitive handling of properties, i.e.,
all the methods setXXX could be renamed to XXX=, and a block oriented wrapping
of signals.  I.e., I would like blocks to be connectable with signeals immediately,
which would be the real Ruby way.

I have attached my intial Ruby script I planned to be the base of this new
wrapper generator. The most complicated part of the script (which I does not assume
to function 100%-ly correctly), is the output of type names and function
declarations based on the internal representation (The with_full_type methods).
However, this will be quite crucial for the planned wrapper generator.

Best regards, Christian