[Kde-bindings] KDE/kdebindings/csharp

[Arno Rehn]

On Wednesday 30 July 2008 14:31:23 Richard Dale wrote:
> On Wednesday 30 July 2008 01:01:28 Arno Rehn wrote:
> > On Monday 28 July 2008 20:13:05 Richard Dale wrote:
> > > On Saturday 26 July 2008 20:56:44 Arno Rehn wrote:
> > > > SVN commit 838125 by arnorehn:
> > > >
> > > > * Use qobject_cast in the KWrite example.
> > > > * If CreateInstance() doesn't find a type, it now replaces the last
> > > > '.' with a '+' and tries again to find nested classes.
> > >
> > > I don't think this is the best way to fix the problem. I think we need
> > > a Dictionary from a C++ classname to the C# type. Then another
> > > Dictionary that we already have to get from the Type to details about
> > > how to construct the instance.
> > >
> > > I'm not sure we need to have a Dictionary or QHash that goes from the
> > > C++ classname to  the C# classname, and then finally get the Type by
> > > walking through all the loaded assemblies. I would have thought that
> > > was pretty slow apart from problems with '+'s and '.'s in  the
> > > classname paths.
> >
> > Yes, it's definitely not the best solution. I think we should fix the
> > problem directly in SmokeBinding::className(). We could dynamically
> > replace every '::' with a '.' and then check if the type exists in C#. If
> > it doesn't, replace the last '.' with '+' and so on... At the end we
> > cache the result. We could then get rid of the static classname-hash
> > initialization in every module, too.
>
> We've always got the C++ class name first in order to have retrieved the C#
> one from the SmokeBinding::className() hash. So I think we should be
> directly retrieving the C# Type given the C++ name. Maybe it is useful to
> have a human readable version of the C# class name that we can retrieve
> from the C++ name, and the binding.className() call could do that. I think
> we should walk through the classes in a newly loaded assembly looking for
> SmokeClass attributes, and build up a Dictionary of C++ names <--> C# types
> that way.
I thought about that first, too. But walking through all the classes of a 
assembly via reflection is quite slow and I don't know if the additional 
overhead is worth it. Actually only around half of the classes in a module, if 
not less, will really be used in a project, I think.

-- 
Arno Rehn
arno at arnorehn.de