[Kde-bindings] const_missing method in ruby 1.8

[Alexander Kellett]

On Tue, Aug 05, 2003 at 11:35:40AM +0100, Richard Dale wrote:
> > after readingthe code i tried all three of them seperately but
> > not yet together. i'll give this a try now :)
> Ok - I'll leave you to it - please check it in, if you think it works. I just 
> tried this in t4.rb:
> quit.setFont(Qt::Font.new("Times", 18, Qt::Font::Bold))
> and it worked fine.

yup, works here also with all three, which one exactly would
Qt::RichText be using? i am still confused by the Internal
class. i'll read over the rest of the code tonight and possibly
write some comments to help other new comers to the code.

and on coding style, i asked on #ruby-lang:
   12:40 < lypanov> whats better:
   12:40 < lypanov> Qt::MessageBox.critical(self, "File Does Not Exist", "Sorry, unable to find the requested file!")
   12:40 < lypanov> or Qt::MessageBox::critical(self, "File Does Not Exist", "Sorry, unable to find the requested file!")
   12:40 < lypanov> ?
   12:40 < lypanov> 2nd is more c++ style
   12:40 < lypanov> and first, is class method style
   12:40 < lypanov> but. erm. maybe just allow both?
   12:41 < batsman> I prefer the first
   12:41 < batsman> I always use :: for constants, . for (class singleton) methods

which was also the idea i got.

so. maybe it would be useful to stop the use of 
non constants (methods) via const_missing in 
order to keep coding style consistant with 
most other ruby?

okay. commited the const_missing pseudo patch.

> > this seems quite evil especially considering that imo
> > kalyptus could just be creating bindings for the actual
> > iterator objects. any reason against that? 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.
> You wouldn't want to see the iterator classes in ruby code though - surely the 
> value lists should just be normal ruby arrays?

not sure i agree here. i think that they should be
wrapped in the ruby itself rather than in handler
code, this is much more generic and probably less 
work in the end. so for example collisions(pos).to_a 
would provide the array of qcanvasitem's.

> I'll try and do the TODO list today - I think we've discussed enough stuff 
> that needs doing for a bit though..

okay, excellent, and i agree :)

Alex