[Kde-bindings] KDE/kdebindings

[Richard Dale]

On Monday 30 November 2009 06:12:38 pm Arno Rehn wrote:
> 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?
If the method is overloaded you need to resolve which method to call using the 
argument types, whereas for non-overloaded methods you can skip that step.

> 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.
Yes, it isn't too hard to make the binding cache all the non-overloaded 
methods when a class is first used. However, it isn't so easy to do it on a per 
method basis when a method is first called, which is what I had in mind.

I was assuming the generator would already know which methods were overloaded, 
and adding the option would be cheap and simple. Maybe we can discuss again 
when I've actually started tuning the QtScript bindings a bit, after the first 
release.

-- Richard