Version: (using KDE Devel) Installed from: Compiled sources This would make ducktyping possible -- instead of checking whether object.class == String, you check whether object.respond_to? :to_s, for example. Unfortunately QtRuby and Korundum don't include the Qt/KDE classes' methods in object.methods, and return false to respond_to? (iirc, this is because everything actually happens in method_missing). If it's not too hard to redefine methods and respond_to? to return the correct values, it'd be great to have. I tried having a look at the code myself, but my foo is weak...
On Monday 16 May 2005 16:55, Gábor wrote: [bugs.kde.org quoted mail] Yes, I agree this should be on the todo list. Certainly it would be nice to have the Qt/KDE methods and constants returned via ruby introspection. Also the methods callable via DCOP with a DCOPRef could be included. It should be possible to change respond_to?, but I don't know if that might have unexpected side effects. The C function rb_respond_to() is used to tell if a virtual method has been overriden in ruby, and that mechanism might not work anymore. -- Richard
Well, you obviously know 10x as much Ruby as I do... but perhaps just alias the old one over to something different and use that internally, and show the redefined respond_to? outwards? On 17 May 2005 16:18:28 -0000, Richard Dale <Richard_Dale@tipitina.demon.co.uk> wrote: [bugs.kde.org quoted mail]
On Tuesday 17 May 2005 20:25, Gábor wrote: [bugs.kde.org quoted mail] Yes, but it needs thinking about - what if method_missing was implemented in terms of respond_to?, and whether or not the C function rb_respond_to() takes into account any subclasses overriding the 'responds_to?' method. I haven't done any tests yet to find out about this stuff. The Smoke library has been optimized for making queries on the name of a method along with the type signature of the args, but 'respond_to?' ignores the type signature of the args - maybe this kind of access can be optimized in a Qt 4.0/KDE 4.0 version of QtRuby. -- Richard
SVN commit 416098 by rdale: * Removed unused Qt::Internal functions * Added KNS:: to the namespaces expected by the rbkdeapi tool * Introspection via Object#methods, public_methods, protected_methods and singleton_methods or Module#constants, instance_methods, protected_instance_methods and public_instance_methods now all include methods from the Smoke runtime. This fixes part of the request in bug 105772, but still not enabling 'respond_to?' to be used with Smoke methods. CCBUGS: 105772 M +4 -1 trunk/KDE/kdebindings/kalyptus/kalyptusCxxToSmoke.pm M +9 -0 trunk/KDE/kdebindings/qtruby/ChangeLog M +100 -31 trunk/KDE/kdebindings/qtruby/rubylib/qtruby/Qt.cpp M trunk/KDE/kdebindings/qtruby/rubylib/qtruby/lib/Qt/qtruby.rb M +5 -1 trunk/KDE/kdebindings/smoke/smoke.h
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
QtRuby only existed for Qt4 and Korundum, which never got updated for 5.x This is unmaintained and any effort towards QtRuby for Qt6 will be from scratch. Therefore, closing this ticket