[Kde-bindings] const_missing method in ruby 1.8

Germain Garand germain at ebooksfrance.org
Tue Aug 5 22:42:58 UTC 2003


Hi,

Le Mardi 05 Août 2003 10:37, Alexander Kellett a écrit :

> On Tue, Aug 05, 2003 at 10:39:58AM +0100, Richard Dale wrote:
> > We'd need specific marshallers for each concrete instance of a QValueList
> > I think, in handlers.cpp. Here are the existing marshallers, so there are
> > some QValueList ones - we would need some more like that for
> > QCanvasItemList etc.

that's indeed what I've done for all relevant classes via macros...
there are not that much, 8 to 10 maybe.

> this seems quite evil especially considering that imo
> kalyptus could just be creating bindings for the actual
> iterator objects. any reason against that? 

this would be good for generic template support, but for plain iterators, IMO, 
that would be just weird and hard to use.
Why would you not want to use the powerful builtin iterators of your target 
language when that's possible?
It's 12x faster (I mean that figure, and that's only after you've implemented 
method caching and optimized things a lot... in the current state, that would 
be rather 50x), it's natural, and it doesn't remove any functionality?

> it seems like
> a far better way that the current system of writing a
> handler for each commonly used type. or, maybe just a
> big set of macros to automate the type handling would be
> enough rather than a smoke extension.
>

actually, you also need to add a suitable regexp to match the method
args when the marshaller can do fromValue...
In current Qt.pm, that looks like
    Q(?:String|Widget|Object|FileInfo)List[\*&]?|
                                  QValueList<int>[\*&]?|
   QPtrList<Q(?:Tab|ToolBar|DockWindow|NetworkOperation)>|

I'd recommend you have a look at pqtapi, it's very handy when you want to scan 
the whole smoke interface, and grep your way through it

> > > this pqtsh thing looks really nice. i'd like to
> > > do something like this in ruby. i wonder if it
> > > uses anything more than perl's introspection or
> > > if PerlQt provides a sort of smoke perl binding?
> >

If you are speaking about the "can't find method... closer candidates: " 
message, it's PerlQt's way of reporting errors when you "use Qt::debug"..

When a method isn't found, instead of dying immediately, I made it simply 
lookup again, reducing the name at each iteration, then dump all the matches

method "foobar"-> look for "fooba", "foob", "foo" 
                             and "oobar", "obar", "bar"

Then you need to have a function able to translate the smoke representation of 
the method into something readable
Qt.xs-> dumpCandidates(rmeths)

> > > p.s: if anyone has a PerlQt checkout, i really
> > >      could use it, as i can't get anything
> > >      whatsoever from sourceforge cvs  :(

ah, right, SourceForge has a lot of troubles those days :-((
here is the current CVS in case you still need it:

http://www.phoenix-library.org/germain/perlqt/PerlQt-3.tar.gz

I still have the 3.2's uic to puic merges to checkin but they are not properly 
debugged yet. Very boring stuff...

Cheers,
Germain




More information about the Kde-bindings mailing list