[Kde-bindings] KDE/kdebindings/csharp

[Richard Dale]

On Wednesday 30 July 2008 14:03:25 Arno Rehn wrote:
> 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.
I think we need to do some actual timing measurements to find out how much 
loads would be slowed down. Maybe we could build a table of C++ names vs. C# 
types at compile time. Anyway, I think the hack we have at the moment is ok 
until we've thought about this a bit more.

-- Richard