From: Martin Man Date: 2002-06-11T22:45:06+09:00 Subject: Re: ruby-qt3 proposal (c++ based extensions) --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 11, 2002 at 10:19:49PM +0900, Christian Szegedy wrote: > 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 interest= ed > >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 slot= s, > >these have to come yet, but it hopefully covers the c++ overloading=20 > >problem.. > > > > >=20 > I proposed a similar solution already. Please refer the last thread on qt. > I could imagine some improvement to your solution: ooops, must have missed this one, but I admit I was checking just ruby-qt yahoo group. > For each qt class with virtual functions an overridable and not overridab= le > version. This would improve performance in the very commmon case, when y= ou > know that you don't want to reimplement any virtual functions. well that sounds nice, but it means walking manually thru all the header fi= les and marking which funtion will be overridable and which not, and this I'm willing to give up in favor of full automatic generation, unless someone wa= nts to make this monkey work (only once, but it has to be done)... > For the overridable class, I would create a function pointer table (playi= ng > 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.=20 this seems quite nice (concerning the speed issues), but how would you catch the method creation (in ruby) so that you can swap the function pointers ?? > 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. yup, I suppose I'm playing with your files, thanx, I've yesterday also craf= ted something that already can produce some basic code, usless yet though... > I planned to write a complete wrapper using this implementation, since the > SWIG has some annoying features including the strangeness for the .new > methods. I hope these were fixed in 1.3.12, that's why I'm proposing to use swig finally, since all this wrapping into VALUES and back is not trivial... > Additionally, I would like to see a more intuitive handling of properties= ,=20 > i.e., > all the methods setXXX could be renamed to XXX=3D,=20 I hope this could be done quite easily in cases where return type of method= is void and method acceppts only one parameter and matches /^set[A-Z][a-zA-Z_]= +/ > 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. yes, that would simply be cool... > Best regards, Christian rgds, martin P.S. I'll take a look at your script, thanx... --=20 The things that make a person a good programmer are the same ones that stop him from being a good manager. -- derrickh @ slashdot.org --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9Bf6nYgJwJG4GAiMRAphWAJ4gzPqNPziaHdlKp2s1jMZJAvj1BQCfQrN1 cTRZzKm6o1j/lKJYlHtMEGA= =WonO -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1--