[Kde-bindings] Problem in QtRuby invoking slots with arg types that are typedefs

Arno Rehn arno at arnorehn.de
Mon Apr 19 19:11:32 UTC 2010


On Monday 19 April 2010 09:16:42 Richard Dale wrote:
> On Sunday 18 April 2010 05:16:37 pm Arno Rehn wrote:
> > On Monday 22 February 2010 18:48:01 Richard Dale wrote:
> > > On Monday 22 February 2010 05:05:08 pm Arno Rehn wrote:
> > > > or add another table or
> > > > field to smoke which links typedefs in signal/slot signatures to
> > > > their real type. The latter is probably better in terms of
> > > > maintainability, but it could require another BIC change, depending
> > > > on how we do the 'link'.
> > > 
> > > Yes, maybe it would be nice to cater for typedefs properly but I don't
> > > think we can afford a BIC change at the moment.
> > 
> > Another idea just came to my mind: we could implement it similar to how
> > ambigious methods are resolved:
> > 
> > We add another entry to the Smoke::TypeFlags enum, called tf_typedef. If
> > this is set, Smoke::Type::classId will be negative and this negative
> > index will point to another entry in the Smoke::types table (which will
> > then be the resolved typedef).
> > 
> > The 'classId' label for the Smoke::Type field isn't ideal anymore, then.
> > But it can be changed without breaking BC since the data structure stays
> > the same. There aren't that many projects using smoke, so a SIC change
> > can be afforded, I think.
> 
> Can't you just not resolve typedefs for arguments to slot and signal
> argument types, and ignore the resolveTypes command line option passed to
> smokegen?
Hm, yes. That'd probably be best for the time being.
I just thought about the automatic generation of Qyoto assemblies from smoke 
libs, where it would be  nice to have information about typedefs. Otherwise we 
have to special-case them again, similar to what we still have to do for our 
marshallers. 

-- 
Arno Rehn
arno at arnorehn.de



More information about the Kde-bindings mailing list