[Kde-bindings] Adding an mf_attribute flag to MethodFlags in smoke.h

[Arno Rehn]

On Tuesday 13 October 2009 12:38:33 Richard Dale wrote:
> On Monday 12 October 2009 09:37:58 pm Arno Rehn wrote:
> > On Wednesday 09 September 2009 18:39:28 Richard Dale wrote:
> > > I think it would be useful if we could add a 'mf_attribute' flag to
> > >  MethodFlags to denote a setter or getter method that was generated to
> > >  access C++ static/member variables:
> > >
> > >     enum MethodFlags {
> > >         mf_static = 0x01,
> > >         mf_const = 0x02,
> > >         mf_copyctor = 0x04,  // Copy constructor
> > >         mf_internal = 0x08,   // For internal use only
> > >         mf_enum = 0x10,   // An enum value
> > >         mf_ctor = 0x20,
> > >         mf_dtor = 0x40,
> > >         mf_protected = 0x80,
> > >         mf_attribute = 0x100  //  Variable getter/setter method
> > >     };
> > >
> > > I think calling it an 'mf_attribute' instead of 'mf_property' will make
> > > it less likely to get it confusesd with a Q_PROPERTY. This would be
> > > useful for languages like python where we want them to be able to make
> > > these methods map onto attribute accessors instead of ordinary method
> > > calls.
> >
> > I thought about creating a new C# sources generator that is directly
> > based on existing smoke libs. Your proposal would be needed for such a
> > thing anyway, so I don't have any objections :). I'd then also flag
> > methods that are accessors for Q_PROPERTYs, so we don't have to duplicate
> > them in the C# sources.
> >
> > A generator based on smoke would simplify things by some extent. We
> >  wouldn't have to duplicate the configuration files and would make the
> >  bindings a bit more dynamic (we could load and even create new bindings
> > on demand, without prior knowledge of the library to bind (using the
> > System.Emit namespace)).
> 
> Yes, but I'm not sure we have the details of the signals, Q_PROPERTY's and
> slots in the smoke lib. Maybe we would need some new method attributes for
> them. An mf_property could be a Q_PROPERTY setter/getter, and mf_attribute
> could be an C++ variable getter/setter. Both would map onto C# properties.
> 
> If we use the PySide comment extractor, and it is adapted to work with
> comments in headers, we don't have to bother with adding them to the C#
> sources anymore.
Oh, I didn't know they already have such a thing.

> > Anyway, I think it's a good idea to add mf_attribute.
> 
> Ah, after I posted the mail I realized the flags are in an unsigned char,
>  and we've run out of space. So it would need to be changed to an unsigned
>  short instead. Maybe wait until we have several BIC changes to smoke.h and
>  do them all at once? Now we have several projects using the Smoke libs we
>  have to be careful to all keep using the same versions.
If we're at it we could also add sizeof() information for classes (for dynamic 
list marshallers) and make init_foo_Smoke() and foo_Smoke extern "C" (as 
suggested by the lisp bindings developer).

> Also I think a 'mf_overloaded' flag would be useful as if a method isn't
> overloaded, there is no need to keep looking it up, and the result of the
>  first lookup can be cached.
Yes, that sounds good.

-- 
Arno Rehn
arno at arnorehn.de