Re: [Swig-user] Developer opposed to using SWIG

[Nathan H. <na...@ma...>]

Thanks for the insightful reply. That's all good food for thought. To get such a detailed response from a lead developer is great. 

Cheers,
Nathan Hand
 

On 15/04/2011, at 12:13 PM, David Beazley <da...@da...> wrote:

> As the original creator of Swig, my response to this criticism is simply "it depends."   How big is this third party library?   What is the complexity of its API?   Is the API going to change a lot?    How much time do you want to spend messing around with it?
> 
> Historically, Swig was created primarily for use by applications programmers working with frequently changing C/C++ code (for instance, in scientific computing where users were constantly making code changes).    By automating the wrapping process, you didn't really have to worry about changes to the underlying code base--such changes would simply show up in the resulting Python interface.      Similarly, if someone had a huge library that they wanted to wrap, Swig could automate large parts of the process.
> 
> I think your developer is basically right that in that even if you use Swig, someone is still going to have to maintain the interface files.   Moreover, there are special cases that you will have to handle.  However,  there are also a lot of very complicated things that Swig *DOES* handle correctly and which are a real pain the ass to write by hand.  For instance, if you're wrapping some library that has 50 C++ class definitions, only a masochist is going to sit down and define 50 Python types directly using the Python C API.     Swig also has a lot of built-in support for proper type checking, casting of pointers, overloaded functions, etc. not to mention a lot of portability features related to different operating systems, compiler flags, etc.
> 
> Also, keep in mind that Swig and hand-written wrappers are not mutually exclusive.  If you know what you're doing, Swig can be used to make a Python interface very rapidly--maybe to put a prototype together.  Over time, you can always moved code into hand-written wrappers if you want.
> 
> Regarding the "complexity" of Swig, it really depends on how you use it.   I for one, hardly ever used the more advanced customization features of Swig and rarely had problems.  On the other hand, there are some developers who feel some need to go completely over the top with typemaps and other insanity.  Frankly, I think a lot of that is just crazy, but that's just me.   I think a common confusion for newcomers is that they think they *have* to do that stuff to use Swig--which is simply wrong.
> 
> As for the "dream of write-once, bind everywhere without any additional effort" comment, do real Swig developers even do that?  Although it might be theoretically possible, I think most users probably just stick with their one favorite language whatever it happens to be. The main benefit of multiple language modules, really, is that you can reuse a lot of Swig's basic C parsing functionality to make a wrapper generator for some new language without having to code the whole thing from scratch.   If you're careful about how you do things, you can make modules that work in multiple languages, but you have to know what you're doing.
> 
> Anyways, my inclination would be to just let the guy do his hand-written wrappers.   If it takes less than a week, it's probably no big deal.  On the other hand, if he's wasting a ton of time for months on end, tell him to just use Swig and get on it with already.
> 
> Cheers,
> 
> Dave
> 
> 
> On Apr 14, 2011, at 8:24 PM, Nathan Hand wrote:
> 
>> 
>> Our organisation has a developer who is opposed to using SWIG for binding a third-party library. He’s keen to develop bindings for his pet language (python) but that would have the unintended consequence of cementing python for all in-house development. His comments are below:
>> 
>> SWIG is just another way to write bindings – it’s not magic and someone still has to write and maintain the SWIG definitions that can be used to generate bindings for various other languages. If it were that easy, and worked so well, everyone would use it, but in reality just about no one does because the price you pay for generality is (high levels) of complexity.
>> 
>> Like many “generic” solutions SWIG fails to handle lots of special cases, and you have to end up coding lots of language-specific exceptions anyway, especially as you start dealing with complex data structures that need to be marshalled from C land to various representations in high-level languages. So you end up with the SWIG-Python bindings, the SWIG-Perl bindings etc, defeating the purpose of a generic binding definition in the first place…
>> 
>> As a result most people avoid the huge overhead and complexity of SWIG and just write language bindings directly – it turns out that once you have written bindings for a given language, it is much easier to just translate the code into bindings for a different language than it is to write a generic mapping using tools like SWIG that usually fail to deliver the dream of write-once, bind-everywhere without any additional effort.
>> 
>> I’m not experienced enough to argue against the developer, although my gut tells me he’s wrong and writing bindings for a single language is ultimately a waste of time. Can the SWIG developers here give me some counter-arguments?
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Benefiting from Server Virtualization: Beyond Initial Workload 
>> Consolidation -- Increasing the use of server virtualization is a top
>> priority.Virtualization can reduce costs, simplify management, and improve 
>> application availability and disaster protection. Learn more about boosting 
>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev_______________________________________________
>> Swig-user mailing list
>> Swi...@li...
>> https://lists.sourceforge.net/lists/listinfo/swig-user
>