title: SWIG: Coping with baseclass overloaded methods in a derived class
body: <p>I'm struggling to make this somewhat elegant in SWIG...</p>
  
  <p>I have a base class which contains an overloaded method create:</p>
  
  <pre><code>class Base {
  public:
      virtual Foo *create(ClassA &amp;, ClassB &amp;) = 0;
      Foo *create(int id) {
          // get ClassA a and ClassB b from an internal store related to id
          return create(a, b);
      }
  };
  </code></pre>
  
  <p>This is of course, SWIG-wrapped without hassle.</p>
  
  <p>In other locations/repositories, there are several different derived classes of Base, which of course define their own version of the pure virtual create(ClassA&amp;,ClassB&amp;) method - but they don't need to define a create(int) variant because the base class version should suffice.</p>
  
  <p>The SWIG wrapping of these derived classes only see the create() method defined in the derived class, and don't provide for the variant with the single int parameter, even though they should inherit it from the baseclass.</p>
  
  <p>I have tried using %rename for the baseclass's methods to get something that works, e.g.</p>
  
  <pre><code>%rename (_create1) Base::create(ClassA&amp;,ClassB&amp;);
  %rename (_create2) Base::create(int);
  
  %extend (Base) {
      %pythoncode {
          def create(self, a_or_id, b=None):
              if b is not None:
                  self._create1(a_or_id, b):
              else:
                  self._create2(a_or_id)
      }
  }
  </code></pre>
  
  <p>This seems fine in the generated python/_wrap.cc code, but the wrapper for the derived class will just wrap the create() method as if the %renames aren't there.</p>
  
  <p>They <em>are</em> in separate .i files, but the derived classes' .i files each import the baseclasses .i file so the python class inheritance is correct, it's just the C++ class inheritance that is somewhat defeated by this overrided method.</p>
  
  <p>Ideally I'd like a solution where I didn't have to insert %rename statements in all of the derived classes' .i files (although I know this would solve the issue), it just means an awful lot of duplicated code. </p>
  
  <p>Any ideas?</p>