From: Richard Dale Date: 2003-07-16T03:19:02+09:00 Subject: Re: Custom method_missing doesn't trap super call Lyle Johnson wrote: I've just sent you a private mail reply, but I'll post it to the newsgroup apart from the qtruby attachment - I assume 32k isn't popular there.. > Richard Dale wrote: > >> With the Swig approach you can't call protected methods, you can't >> override virtual methods, and it doesn't have a mechanism for dealing >> with method overloading very well (particularly important with >> constructors). With Smoke I get all that for free, and I don't even need >> to parse any headers/write interfaces etc. > > For the record, SWIG 1.3.20 will provide support for overriding C++ > virtual methods with Ruby instance methods; this code is already > available in the SWIG development CVS. Method overloading has been > available since SWIG version 1.3.14 or so, and works very well for > constructors as well as regular functions. Oops, I'm sorry if I sounded a bit rude about SWIG, it sounds as though it's making good progress. I started generating Qt/KDE bindings with a version of kdoc (a tool written in perl which parsed headers and produced html), called 'kalyptus'. I added a kalyptus ruby generation option based on producing the same code as SWIG about a year and a half ago, but got stuck with the method overloading. I think Nobuyuki Horie had to do a lot of hand fixing for the RubyQt bindings for Qt2. Then Ashley Winters came along with the idea of SMOKE. That stands for 'Scripting Meta Object Kompiler Engine', it works like the moc tool in Qt which adds some runtime dynamism to static C++ applications via a preprocessor, but just for slots, signals and properties. SMOKE does the something similar, but for the entire api. > On a side note, I hadn't heard about Smoke, and so I was doing some > quick googling for it. It sounds pretty cool. Am I basically correct > that it is a Qt (or maybe Qt+KDE) specific library that can be used to > build different language bindings to Qt? In other words, it is not a > general purpose "wrapper" generator like SWIG? The SMOKE bindings are currently generated with kalyptus by parsing headers. But Ashley is working on a tool which parses the compiled translation unit for a library, which he thinks will be more precise. I don't think anyone on the kdebindings list is really thinking about general purpose tools like SWIG, and Qt/KDE has it's own specific problems like how to deal with slots/signals. But I can't see why the idea couldn't be used with other large C++ libraries. I think you'll always need to write marshalling code - typemaps in SWIG or the marshalling in handlers.cpp in the attached qtruby code. And I don't know whether or not the bindings lib has a dynamic runtime would be noticed by a user. The advantage for KDE of a common shared library like libsmokeqt.so is that it can be loaded at start up by the kdeinit process, and then the language extensions are very small and quick to load. -- Richard