[Kde-bindings] KDE/kdebindings

[Arno Rehn]

On Monday 30 November 2009 16:05:39 Richard Dale wrote:
> 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.
Ah, I see. But couldn't you just cache the xcall_ function and index even if 
the method is overloaded? Just cache the munged name and/or method signature 
as well, so looking it up again will be very easy once you have the method 
signature/munged method name. I haven't taken a closer look at the QtScript 
bindings, am I missing something?
Sorry for being so reluctant, but adding an mf_overloaded flag would increase 
the time the generator needs even more. Currently I think something like 
caching should entirely be implemented in the binding itself, including stuff 
that has to do with overloaded methods.

-- 
Arno Rehn
arno at arnorehn.de