[OpenBabel-scripting] OBDotNet v0.3

[Matt S. <mes...@gm...>]

I'm finished with v0.3 of the .Net bindings. Before I upload the changes I
have a couple of questions. I may have asked some of these before, but it's
been awhile.

1) In the new bindings I've implemented a system to preserve inheritance
chains when returning classing from unmanaged code (type factory with cached
delegates for dynamically constructed methods FTW!). This means that we no
longer need the ugly Cast methods on OBGeneric data. Should I remove them or
mark them as deprecated to give end users some warning and remove them in
the next version?

2) A couple support classes like the aforementioned type factory are
currently implemented in stand alone source files. Where should I put them
to avoid screwing up the non-VS build? If necessary I can make them internal
to the imclass, but I'd prefer not to as it would make the interface file
much longer.

3) I've found it advantageous to split up the swig instructions into
multiple interface files as follows.
    -openbabel-csharp.i -> interface file processed through swig in
\scripts\
    - obswig_ignores.i -> master list of ignored classes/methods
    - obswig_macros.i -> useful macros for things like wrapping overloaded
operators
    - ob_enums.i -> definitions of enums that force swig to generate enums
for groups of global constants defined in header
                             files (much easier for end users to understand
than having dozens of constatns in a module class)
    - multimap.i -> multimap wrapper for fast search (not currently a part
of swig C# or java)
    - stl_streams.i -> minimal stream class definitions for java and C#

   Currently I've got the supporting interface files in  \scripts\swigcommon
so that they can be used by both the java and C#                interface
files. Is that acceptable? If so, I know that the make files will need to be
updated. Can someone who is more familiar          with  the build process
handle that after check in?

4) Functions defined in header files with unnamed parameters really cause
problems when applying typemaps. For example,            SomeFunc(int*),
SomeOther(int*) can't have to different typemaps for the parameters. Can we
go through and name all the              currently unnamed parameters? The
only workaround for swig is to ignore the method and extend the class
definition with an            identical method with named parameters. That
gets pretty ugly.

Let me know what you think about this stuff and I'll start checking in the
new code.

-Matt