[Kde-bindings] KDE/kdebindings

[Arno Rehn]

On Friday 27 November 2009 18:26:55 Richard Dale wrote:
> 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.
I committed the mf_signal and mf_slot additions now. But I still can't quite 
figure out the use case for an mf_overloaded flag. If we have a pointer to a 
Smoke::Method and we know that it's overloaded, what can we then do with that 
information? Wouldn't we at least need to know which methods *are* the 
overloads to do anything useful?

-- 
Arno Rehn
arno at arnorehn.de