Re: Combining modules and namespaces

Hi Hans

There probably ought to be a way to obtain the module name pertinent to a
class, but I can't find one. The closest I can think of is $module is
expanded to the module name, but it expands to the current module (defined
by the main %module directive, or -module). I can't see any way to obtain
the module name that a class was parsed in using %import(module="abc"), see
http://swig.org/Doc4.0/Modules.html. Sorry.

William


On Thu, 30 Jan 2020 at 18:19, Hans Packet <[email protected]> wrote:

> Hi William,
>
> thanks for the suggestions. I would like to dig a bit deeper into
> suggestion 1: while it definitely fixes the problem, a drawback is that I
> would need to create this typemap (and also csin typemaps) for each type
> that could encounter this problem.
>
> To reduce much of the manual work we already had (as mentioned,
> maintainability is important), I have grouped all kinds of fixes and
> customizations in a bunch of macros. Something like:
>
> %define %my_class(CPP_NAMESPACE, TYPE)
> // ... a bunch of typemaps
> %enddef
>
> %my_class(ns, MyClass1);
> %my_class(ns, MyClass2);
>
> Adding the cstype/csin fix to this macro would be a good fit:
>
> %define %my_class(CPP_NAMESPACE, TYPE, CS_NAMESPACE)
> // ... a bunch of typemaps
> %typemap(cstype) CPP_NAMESPACE::CPP_TYPE "CS_NAMESPACE.TYPE"
> %enddef
>
> %my_class(ns, MyClass1, RootNs.Ns);
> %my_class(ns, MyClass2, RootNs.Ns);
>
> The main problem with this, is that I would need to explicitly pass the C#
> namespace to the macro for each type (and I have quite a lot of them). It's
> doable, but I'm just wondering if there is a more automated way to do this.
> Since I have defined 1 module per namespace, it would be sufficient to
> define some kind of namespace 'constant' once per-module, and use it inside
> these macros, without having to explicitly pass it in. Maybe I'm thinking
> too much in terms of the C preprocessor, but something like the following
> would be nice:
>
> #define CS_NAMESPACE RootNs.Ns
>
> %define %my_class(CPP_NAMESPACE, TYPE)
> // ... a bunch of typemaps
> %typemap(cstype) CPP_NAMESPACE::CPP_TYPE "CS_NAMESPACE.TYPE"
> %enddef
>
> %my_class(ns, MyClass1);
> %my_class(ns, MyClass2);
>
> This obviously doesn't work, and I couldn't find anything similar to
> accomplish this, except for preprocessing the swig definition files myself.
> But maybe there's a way to do it that I didn't find yet. Do you have any
> suggestions on how to accomplish something like this ?
>
> Kind regards,
> Hans
>
> On Tue, Jan 28, 2020 at 9:49 PM William S Fulton <[email protected]>
> wrote:
>
>> Hi Hans
>>
>> A couple of ideas:
>> 1. Try using the 'cstype' typemap to add in the appropriate namespace to
>> the C# type, thus qualifying with a C# namespace.
>> 2. SWIG mirrors the C++ API, so how about changing your C++ API to use
>> the multiple namespaces and use -nspace with SWIG. For C++ users, you can
>> always add in a 'using' statement to put them all back into the  one C++
>> namespace. So effectively no change for C++ users.
>>
>> William
>>
>> On Tue, 28 Jan 2020 at 13:46, Hans Packet <[email protected]> wrote:
>>
>>> I'm trying generate C# bindings for a c++ API, and I'm running into
>>> problems with the combination of modules and namespaces.
>>>
>>> Some context on the problem I'm trying to solve: most of my c++ API is
>>> defined in a single namespace. For the C# API, it was preferred to have a
>>> more finegrained namespace structure. As far as I can see, the nspace
>>> feature can't accomplish that exactly though. For that reason, I have tried
>>> to use an alternative approach: split up the swig binding into multiple
>>> modules (one per namespace), and use the -namespace cl argument for each of
>>> the modules. Note that many of the modules depend on other modules. This
>>> works well, except that I run into a few problems:
>>>
>>> a) Other modules don't know anything about the namespace of an other
>>> module. I'm working around this by adding
>>>   - %typemap(csimports)
>>>   - %pragma(csharp) imclassimports
>>> This works ok, but it is manual work, i.e. harder to maintain. This is
>>> not a critical problem, but it makes the definition files harder to write.
>>>
>>> b) I end up with naming clashes in a very specific case. When a method
>>> argment type has the same name as the method itself, C# doesn't correctly
>>> resolve this. Example of the generated C# code:
>>>
>>> using Ns;
>>>
>>> void Rectangle(Rectangle rect) {
>>>   xxxPINVOKE.Xxx_Rectangle(swigCPtr, Rectangle.getCPtr(rect));
>>>   // ...
>>> }
>>>
>>> When using the nspace feature (which I probably can't use), this is not
>>> an issue, because the generated C# code ends up as:
>>>
>>> void Rectangle(Ns.Rectangle rect) {
>>>   xxxPINVOKE.Xxx_Rectangle(swigCPtr, Ns.Rectangle.getCPtr(rect));
>>>   // ...
>>> }
>>>
>>> You could argue that a method name should not be the same as the method
>>> argument's type, but in many cases (within the naming conventions that are
>>> used), it does make sense. So I would like to avoid renaming the methods if
>>> possible.
>>>
>>>
>>> My general question would be: Am I taking the correct approach to solve
>>> the 'single c++ namespace -> multiple C# namespaces' problem ? Or is there
>>> a better way to do this ? If you have suggestions to solve the sub-problems
>>> (a) and (b), that would be welcome too.
>>>
>>> Note: I came across a similar question in this mailing list, but it
>>> doesn't give a complete solution to my problem. It's also 10 years old, so
>>> a better solution might be available now.
>>> https://sourceforge.net/p/swig/mailman/message/24058732/
>>>
>>> Let me know if you need more information.
>>>
>>> Thanks,
>>> Hans
>>> _______________________________________________
>>> Swig-user mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>>
>>

_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user