The "copy, sed, patches" strategy is actually the strategy that I was about to deploy after all in my environment so I'm really happy to see it's in line with the recommended strategy.
 
But being able to specify the method name in the %typemap would just have been much simpler to deploy in my situation so I wanted to see first if this was possible.
 
But if it's not possible then I will go with the full solution.
 
Thanks !
----- Message d'origine -----
De: Marvin Greenberg <public.marvin@gmail.com>
Date: Mercredi, 5 Septembre 2012, 12:38 pm
Objet: Re: Re : Re: [Swig-user] How can I specify different typemaps depending on the method being wrapped ?
: eric.cabot@videotron.ca
Cc: William S Fulton <wsf@fultondesigns.co.uk>, "swig-user@lists.sourceforge.net" <swig-user@lists.sourceforge.net>

> On 12/Sep/5 11:52 AM, eric.cabot@videotron.ca wrote:
> >Thank you guys for your feedback.
> >You are right Marvin the %typemap(out) seems to support a
> signature like "MyType MyClass::MyFunction" but effectively the
> %typemap(directorout) seems not.
> >But even if it did there are still other cases where I don't
> know how to specify the method name.
> >For instance consider the following two methods of the same class.
> >int foo1( Type value );
> >int foo2( Type value );
> >Say I want to apply a different "%typemap(in) Type" to each
> method how can I do this with the argument name being the same ?
> >BTW in my case I cannot write an interface file so I'm stuck
> with doing a %include of the original C++ .h file that has those
> two methods.
> >
> Hmm.  Although you say you are stuck including the original
> .h file, obviously you are not.  You could copy it, run it
> through sed, apply patches, etc.
>
> If you look at the documentation section "5.7 An interface
> building strategy", and especially "5.7.3 Why use separate
> interface files" it recommends that you write separate interface
> files.  We're doing fairly complicated stuff with swig,
> wrapping static and generated c++ APIs, and we use separate
> interface files to give us control over exactly how parts of the
> wrappers get generated.  So you COULD rename, from your example,
>
> int foo1(Type special_arg);
> int foo2(Type special_arg);
> int foo3(Type plain_arg);
>
> And then "in" typemaps to apply differently would be possible.
> Note my extension of the example -- by rewriting the argument
> names, the interface itself now is self-documenting at when you
> are using the different typemaps.
>