[Kde-bindings] KDE/kdebindings

[Richard Dale]

On Friday 27 November 2009 04:49:43 pm Arno Rehn wrote:
> On Thursday 26 November 2009 12:47:24 Richard Dale wrote:
> > On Wednesday 25 November 2009 09:24:14 pm Arno Rehn wrote:
> > > On Wednesday 25 November 2009 20:15:12 Richard Dale wrote:
> > > > On Wednesday 25 November 2009 07:10:32 pm Arno Rehn wrote:
> > > > > SVN commit 1054240 by arnorehn:
> > > > >
> > > > > Add mf_virtual and mf_purevirtual method flags to SMOKE and make
> > > > > generator flag the methods accordingly.
> > > >
> > > > Looks good. Would it be possible to have an mf_signal attribute too?
> > > > That would be useful for the QtScript bindings which need to do
> > > > something different for calls on signal methods.
> > >
> > > Yes, but you can obtain information about signals and slots from the
> > > meta object anyway. That's how I want to do it in the C# assembly
> > > generator, too. Just call staticMetaObject() via smoke and you have all
> > > the information available in the QMetaObject.
> >
> > That is ok to do once at code generation time, but it is too slow to do
> > at runtime with the QtScript bindings. For every method call (even for
> > non- signals) I would need to search through all the signal entries in
> > the QMetaObject and its parents. If there is a mf_signal flag I can look
> > up the method as usual in the smoke lib, and then special case any
> > signals I find.
> 
> Agreed. Should we also add an mf_slot then, just to be on the safe side?
Yes, I don't see why not - there may be a language in the future that it would 
be useful for. Maybe if we know something is a slot then we can go to the 
QMetaObject to get the full details, and that would help with introspection 
tools.

> > Similary it is possible to determine whether or not a method is
> > overloaded in the smoke lib as all the info is there, it just isn't easy
> > to do it efficiently at runtime and a mf_overloaded flag would be a
> > really useful for optimization IMHO.
> 
> I don't know the code in question, but if you have a the methodMap for the
> relevant method, you can simply check for the 'method' field being < 0
> (because then it's ambigious and thus overloaded) or if that isn't the
>  case, check one index before and after this method map if it has the same
>  method name and the same class (then it's also overloaded). The
>  methodMap[] table is sorted by class, then by method name, so this should
>  be pretty fast. If that doesn't work, adding mf_overloaded is fine with me
>  as well.
I thought the ambiguous value being negative was in the context of a 
particular munged method signature, and not for the method in general. If we 
have to search backwards and forwards in the method map that sounds a bit 
clumsy to me. So as long as we are not going to run out of method flags I don't 
think a mf_overloaded flag does any harm.

-- Richard