From: Richard Dale <Richard_Dale@...>
Date: 2003-07-15T19:35:47+09:00
Subject: Re: Custom method_missing doesn't trap super call

Yukihiro Matsumoto wrote:

> In message "Re: Custom method_missing doesn't trap super call"
>     on 03/07/15, Richard Dale <Richard_Dale@tipitina.demon.co.uk> writes:
> 
> |Perhaps I should explain more what about I was trying to do - I didn't
> |want to over complicate the problem description. I'm working on bindings
> |to a C++ gui library Qt, and use a C method_missing (in the C 'Qt'
> |extension) to forward the calls to the C++ methods from ruby. When
> |virtual methods are overriden in ruby, like QPushButton::paintEvent(), it
> |uses rb_respond_to() to see whether or not there is a ruby version of the
> |method.
> 
> I understand what you want.  But why use method_missing?  If Qt has
> finite set of methods, why don't you define wrapper methods just as
> Swig does?
The code is based on the PerlQt bindings project which use perl autoloading
to do what I want to do with method_missing in ruby. The clever thing about
it that it allows you to write adaptors for a language independent backend
library called 'Smoke', with very little code. I've just started with the
perlguts code in the perl adaptor and hacked it to work the same way in
ruby. It already does quite a lot - the paintEvent example works apart from
the 'super' call - everything else is fine.

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.
 
> This does not mean I'm refusing "method_missing for super".  I'm still
> thinking.
OK no problem - but from the method names, maybe the perl autoload feature
was intended to load native methods on demand, but perhaps method_missing
was aimed at custom error trapping? 

-- Richard