A question concerning SWIG

[Rush Manbert <ru...@manbert.com>]

I have a Thrift service implemented as a C++ library. It is used locally to serve a database to multiple local client applications.

We also have a web site that is mostly implemented in java. We have identified a requirement for the web site java code to do something that is both complicated, and is already implemented in my Thrift service C++ library.

We could expose the C++ service to the java code by writing a daemon to run on the web site machines. However, there is a concern about scalability. There is also a concern that the "client side" developers would need to deliver the daemon binary to he "server side" developers. Essentially it makes us maintain another product, even if it's only distributed internally. (There is also the issue that we really have more than one of these C++ library implementations that would be useful to java. We really worry about the performance if the java needs to perform hundreds of operations using the C++ library and the interface is service-based.)

It was suggested that we investigate whether we could use SWIG to wrap the C++ library. That way, our java code could use the functionality by linking a library, rather than sending a message to a service.

The first step of that investigation was to try and wrap a C++ class definition generated by the Thrift compiler.

That fails, but only because of the nested structure definition for the __isset member of the class. For instance, if my Thrift generated class is named foo, the code in foo_types.h looks like this:

class foo {

... other stuff

  struct __isset {
    __isset() : dataMember0(false), dataMember1(false) {}
    bool dataMember0;
    bool dataMember1;
  } __isset;

};

This is convenient, but SWIG chokes on the nested structure definition. This could be avoided if the __isset class were defined separately. Then foo_types.h would look more like this:

typedef struct foo__isset {
  foo__isset() : dataMember0(false), dataMember1(false) {}
  bool dataMember0;
  bool dataMember1;
} foo__isset;

class foo {

... other stuff

  foo__isset __isset;

};

As far as I can tell, this has no effect on any of the code. It does pollute the namespace a little bit, but it seems acceptable to me.

Would making a change like this, possibly dependent on a compiler command line flag, be acceptable to the developer community? Or is using SWIG on Thrift objects just abhorrent?

- Rush

Re: A question concerning SWIG

[Rush Manbert <ru...@manbert.com>]

On Jan 6, 2010, at 1:04 PM, David Reiss wrote:

>> typedef struct foo__isset {
>> As far as I can tell, this has no effect on any of the code. It does
>> pollute the namespace a little bit, but it seems acceptable to me.
> I've been trying to guide all new namespace pollutions to use leading
> underscores.  That way we can disallow leading underscores in Thrift
> identifiers and all pollutions will be safe, so maybe ("_foo__isset")?

Sounds good.

> 
>> Would making a change like this, possibly dependent on a compiler
>> command line flag, be acceptable to the developer community? Or is
>> using SWIG on Thrift objects just abhorrent?
> Fine with me.  It's probably not necessary to make it a compiler option.
> If it breaks, we can always revert and make it so.

Cool. I've looked at the code generator and it looks like a fairly easy change. (Easier than the python post-processing script I was contemplating if the answer was "no way".) I'll see what I can come up with.

- Rush

Re: A question concerning SWIG

[David Reiss <dr...@facebook.com>]

> typedef struct foo__isset {
> As far as I can tell, this has no effect on any of the code. It does
> pollute the namespace a little bit, but it seems acceptable to me.
I've been trying to guide all new namespace pollutions to use leading
underscores.  That way we can disallow leading underscores in Thrift
identifiers and all pollutions will be safe, so maybe ("_foo__isset")?

> Would making a change like this, possibly dependent on a compiler
> command line flag, be acceptable to the developer community? Or is
> using SWIG on Thrift objects just abhorrent?
Fine with me.  It's probably not necessary to make it a compiler option.
If it breaks, we can always revert and make it so.

--David