2009/12/29 Matt Sprague <[email protected]>: > 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?
I'd prefer to mark as deprecated. > 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. If you just stick them in scripts/cpp or so, it would be fine. > 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? I'll sort it out. > 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. Are you happy to identify and correct these or do you need a hand? > Let me know what you think about this stuff and I'll start checking in the > new code. > > -Matt > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ OpenBabel-scripting mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
