[Kde-bindings] KDE/kdebindings

[Richard Dale]

On Monday 09 June 2008 13:28:13 Arno Rehn wrote:
> > The only thing I don't like is subclassing SmokeInvocation and giving it
> > a different name in the generated code. That seems pointless and ugly to
> > me any old static constructor will load the smoke lib. In the soprano
> > bindings I had a source called 'Soprano.cs' with this:
> >
> > namespace Soprano {
> >       using Qyoto;
> >       using System;
> >       using System.Runtime.InteropServices;
> >
> >       public class InitSoprano {
> >               [DllImport("libsoprano-sharp", CharSet=CharSet.Ansi)]
> >               static extern void Init_soprano();
> >
> >               static InitSoprano() {
> >                       Init_soprano();
> >               }
> >       }
> > }
> >
> > And just left SmokeInvocation as it was in the generated code. So I think
> > we should have a Kimono.cs source with the same thing in it.
>
> My intention was to simplify the code for those who actually use the C#
> bindings. And a static constructor is called when the class that defines it
> is used for the first time. Since SmokeInvocation is always used before any
> other thing, it makes sure that the smoke lib is always loaded. If we put
> that code into another class that is completely unrelated to the binding,
> we will always have to call InitFoo() if we want to use it. So subclassing
> SmokeInvocation for the different bindings seemed to be the best solution
> to me.
OK, I understand the problem now, but I still think the solution of renaming 
SmokeInvocation is ugly. I found this after a bit of googling:

"Note, however, that you *can* put code in your AppDomain to execute when
*another* DLL loads. (The AppDomain.AssemblyLoad event.) That means you
can write your code once, and so long as that event handler is added
before the other assemblies are loaded, you can do all the appropriate
things."

http://osdir.com/ml/windows.devel.dotnet.cx/2004-01/msg00064.html

So is the Qyoto dll in an AppDomain, or can we put it in one?

> > When I tried to compile the Kimono code I got an error about an
> > unimplemented abstract method. I wonder if the easiest thing to fix that
> > is to have partial classes with the missing methods in them with empty
> > bodies.
>
> Mh, I thought I had marked all the classes 'abstract' by hand that gave
> errors. Maybe we need to look if all abstract members are implemented in a
> subclass of an abstract class and if not, mark it abstract as well.
The problem is that in C++ you can actually instantiate a class that has only 
some of the pure virtual methods of a super class implemented. So instead of 
abstract methods we need to add empty actual methods to avoid needing to make 
the class abstract. Maybe we can do it automatically. I had the same problem 
with the Soprano StorageModel class which is missing a load of methods that 
are pure virtual in the super class.

-- Richard