[Kde-bindings] const_missing method in ruby 1.8

[Richard Dale]

On Tuesday 05 August 2003 21:04, Richard Dale wrote:
> On Tuesday 05 August 2003 20:15, Alexander Kellett wrote:
> > On Tue, Aug 05, 2003 at 10:39:58AM +0100, Richard Dale wrote:
> > > It probably won't involve a change to do_method_missing in Qt.rb. It
> > > might just be a matter of adding this in Qt.cpp, Init_Qt():
> > >
> > >     rb_define_singleton_method(qt_base_class, "const_missing", (VALUE
> > > (*) (...)) class_method_missing, -1);
> > >     rb_define_singleton_method(qt_module, "const_missing", (VALUE (*)
> > > (...)) module_method_missing, -1);
> > >     rb_define_method(qt_base_class, "const_missing", (VALUE (*) (...))
> > > method_missing, -1);
> > >
> > > Just add three new overrides for 'const_missing' which point to the
> > > same C functions as the three 'method_missing' equivalents.
> >
> > oops. not quite perfect. SIGNAL/SLOT are due
> > to this now handled by const_missing rather
> > than the defined methods (as in ruby all cap
> > identifiers are constants). and are thus
> > quite hellishly broken :)
> >
> > so, here's a patch to hack this in my adding
> > the ability to return a value to the user in
> > the rb do_method_missing itself. this improves
> > the .rb files flexibility a tad, though it's
> > quite a bit of a hack.
> >
> > possibly you have some better ideas for a fix?
> > if so, feel free to revert the commit, but as
> > the bindings are pretty useless at the moment
> > commiting felt like the right thing to do :)
> >
> > (or reverting the const_missing change, but
> >  for some reason i've always detested going
> >  back as opposed to fixing it :))
>
> Oops! We need to think through the error checking for const vs. method
> calls. Maybe this check can be removed if we refactor the C functions a bit
> so they do something different for const missing:
>
> 			else
> 				fail "\n\t\tcouldn't resolve call to
> #{klass}.#{method_original}(#{args.join ","}) (resolving to the c++
> equivalent of #{classname}::#{method_original})\n" +
> 				       "\t\tis it possible that you simply mispelled a local variable
> access?\n"
> 			end
>
> I'd like to think about it a bit more. SLOTs and SIGNALs will alway have
> brackets () after them, whereas constants won't. So we shouldn't have to
> special case them
>
> I tried to get the script name to appear in the window title this afternoon
> but couldn't get it to work annoyingly. Too hot, too hot in the UK..

Ah, I just thought the thing that I changed was to remove the 'include Qt'
from the Init_Qt() function. So the SLOT and SIGNAL calls would need to be
qualified with a Qt::, unless you had a 'include Qt' line at the top of your
script.

So I don't know if SLOT() and SIGNAL() should probably be a global scope, but
the same thing happens in java, and you need Qt. qualifiers on SLOT and
SIGNAL.

-- Richard