Swig renaming of C++ classes for Ruby bindings...

["Darryl L. Pierce" <dp...@redhat.com>]

In testing the Ruby bindings on RHEL 5.8 I hit a weird problem regarding
class name collisions. Specifically, when an instance of the C++ classes
was created within the C++ code and then the Swig layer tried to bind it
for Ruby Swig was using the Ruby classes I had written with the same
name instead.

A more concrete example is:

1: conn = Qpid::Messaging::Connection.new
2: conn.open
3: session = conn.create_session
4: puts "Session is a #{session.class}"
5: puts "Session's impl is a #{session.session_impl}"

Lines 1-2 work fine. Within the constructor for
Qpid::Messaging::Connection it explicitly calls the constructor for
Cqpid::Connection so that's fine.

The problem comes up when we look at the result of 3 via lines 4-5. In
line 3 the code calls Qpid::Messaging::Connection.create_session which
makes a call to Cqpid::Connection.createSession and then wraps the
result.

What's being returns from that underlying call, though, is an instance
of Qpid::Messaging::Session and not Cqpid::Session. The Swig bindings
appear not to be able to tell the difference between two similarly named
classes that are in two different modules.

So what I've done locally is to use the swig %rename directive to rename
the classes Address, Connection, Duration, Message, Receiver, Sender and
Session to have "Cpp" as their name prefix. This way Swig won't get
confused when wrapping objects created in C++.

Additionally, it makes calls to the underlying C++ objects more
discernable in the Ruby wrapper code.

Thoughts?

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/