[Kde-bindings] KDE/kdebindings

[Richard Dale]

On Saturday 28 November 2009 11:13:12 pm Arno Rehn wrote:
> 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?
> 
I actually wanted to easily know if a method was *not* overloaded. If it isn't 
then you can just cache the pointer to the xcall_ function and index of the 
method and call it directly in the future without needing to do any method 
lookup. I was thinking of doing this for the python smoke bindings which don't 
exist yet, but it could be done for the QtScript ones to and they work in a 
similar way.

-- Richard