Hi, Andrew, On Jan 6, 2010, at 0:01 , Andrew Ross wrote:
> We'd of course welcome any contributions for a ruby binding to plplot. I'll be happy to contribute it. It's coming along. > How are you generating it? I'd strongly recommend looking at swig > (http://www.swig.org) for automatically generating them. We use this > for several existing bindings. It would greatly decrease the > maintenance > overhead to use this again. We've also found it very useful, and once > the initial setup is done, relatively easy to use. I have used swig to generate bindings to other libraries in the past. It is impressive how many languages it supports, but IMHO it suffers somewhat from the jack-of-all-trades-master-of-none syndrome. Sure, it can generate bindings to a library for loads of languages from not much more than a header file, but I find that the easy-to-generate bindings are often not very natural feeling in the target language. To get the bindings to be more natural feeling in the target language involves language specific (and often function and/or argument specific) typemaps. Once one starts down the path of target language specific "customizations", the value of swig rapidly diminishes (IMHO) to the point of being seriously questionable as to whether it is a net gain at all over "hand crafted" bindings. Again, this is all IMHO, YMMV. I am following the coding model used in Ruby's PGPLOT bindings, which has its own semi-custom but relatively simple (ruby-only) code generation script for many of the API calls. The code generator supports any function that: 1. has only non-pointer input arguments (other that "const char *"), and 2. has all output arguments (if any) after the input arguments (if any) 3. has no arguments that one might want to make optional For the remaining functions, the bindings for most follow a very similar design pattern which makes the coding go relatively fast. Learning PLplot along the way slows thing down slightly but it's really a nice benefit for me! Another (admittedly somewhat selfish) reason for this approach over the swig approach is the desire to mimic the Ruby PGPLOT interface as closely as possible/practical so I can more easily convert my existing Ruby scripts that use PGPLOT over to using PLplot. :-) I'll keep you posted on my progress, Dave ------------------------------------------------------------------------------ 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 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
