[Swig-devel] Using different wrapping approaches for different Java enums

[Vadim Zeitlin]

Hello,

It seems like it isn't currently easily possible to use different
approaches for different Java enums, e.g. to wrap most of them as proper
Java enums but also wrap some specific ones as "type unsafe" to allow their
use as bit masks. I naively thought that doing something like this:

%include "enums.swg"
... some code using enums ...
%include "enumtypeunsafe.swg"
%javaenum(typeunsafe) SomeBitMaskEnum
... declaration of SomeBitMaskEnum ...
%include "enums.swg"
... some more code using enums ...

would work, but it doesn't because the second inclusion of enums.swg is
silently ignored and so type unsafe wrappers are used for all enums used
after the enumtypeunsafe.swg inclusion, even those that had been previously
wrapped as proper enums.

Right now I work around this by manually reproducing the typemaps from
enumtypeunsafe.swg in my own SWIG file and it does work, but is not
especially nice nor maintainable, so I'd like to find some better way of
doing it.

I can think of two:

1. Allow forcing the second inclusion of the same file, e.g. allow writing

%include(multiple=1) "enums.swg"

or something like this to allow including it again to undo the effects
of enumtypeunsafe.swg.

2. Add some new files enum_proper.i, enum_typeunsafe.i etc which would
define macros defining the typemaps for the given type. Then enums.swg
and company would just include enum_proper.i and invoke
SWIG_ENUM_PROPER_TYPEMAPS(SWIGTYPE) and my code could do

%include "enum_typeunsafe.i"
SWIG_ENUM_PROPER_TYPEMAPS(SomeBitMaskEnum)

to change the typemaps for just this particular enum without changing
the global typemaps and java:enum feature at all.

(1) seems a bit simpler to do and could be possibly be useful elsewhere,
but (2) seems cleaner to me. Which one of these approaches would you
prefer? Or maybe you see some other, better, way of doing this? Or perhaps
you don't think this is a problem, or at least a problem worth fixing, at
all? In this case I'd rather avoid spending time on preparing a patch, but
IMHO doing what I want should be allowed and it would be nice if it could
be done without explicitly writing out all the typemaps.

Thanks in advance for your thoughts,
VZ

[William S Fulton]

Post by Vadim Zeitlin
Hello,
It seems like it isn't currently easily possible to use different
approaches for different Java enums, e.g. to wrap most of them as proper
Java enums but also wrap some specific ones as "type unsafe" to allow their
%include "enums.swg"
... some code using enums ...
%include "enumtypeunsafe.swg"
%javaenum(typeunsafe) SomeBitMaskEnum
... declaration of SomeBitMaskEnum ...
%include "enums.swg"
... some more code using enums ...
would work, but it doesn't because the second inclusion of enums.swg is
silently ignored and so type unsafe wrappers are used for all enums used
after the enumtypeunsafe.swg inclusion, even those that had been previously
wrapped as proper enums.
Right now I work around this by manually reproducing the typemaps from
enumtypeunsafe.swg in my own SWIG file and it does work, but is not
especially nice nor maintainable, so I'd like to find some better way of
doing it.
1. Allow forcing the second inclusion of the same file, e.g. allow writing
%include(multiple=1) "enums.swg"
or something like this to allow including it again to undo the effects
of enumtypeunsafe.swg.
2. Add some new files enum_proper.i, enum_typeunsafe.i etc which would
define macros defining the typemaps for the given type. Then enums.swg
and company would just include enum_proper.i and invoke
SWIG_ENUM_PROPER_TYPEMAPS(SWIGTYPE) and my code could do
%include "enum_typeunsafe.i"
SWIG_ENUM_PROPER_TYPEMAPS(SomeBitMaskEnum)
to change the typemaps for just this particular enum without changing
the global typemaps and java:enum feature at all.
(1) seems a bit simpler to do and could be possibly be useful elsewhere,
but (2) seems cleaner to me. Which one of these approaches would you
prefer? Or maybe you see some other, better, way of doing this? Or perhaps
you don't think this is a problem, or at least a problem worth fixing, at
all? In this case I'd rather avoid spending time on preparing a patch, but
IMHO doing what I want should be allowed and it would be nice if it could
be done without explicitly writing out all the typemaps.

Yes, I'm afraid these were designed to use just one enum approach
across a project. To make these more flexible I think we should
instead use named typemaps. So where you see SWIGTYPE in
enumsimple.swg, change it to ENUMSIMPLE, and add a %apply at the end
to keep it working as is:

%apply enum ENUMSIMPLE { enum SWIGTYPE }
%apply enum ENUMSIMPLE & { enum SWIGTYPE & }
%apply const enum ENUMSIMPLE & { const enum SWIGTYPE & }

In order for you to use these more explicitly a SWIG_ENUM_PROPER macro
(I don't think we need to call it SWIG_ENUM_PROPER_TYPEMAPS) would
just %apply these named typemaps and add in the appropriate %javaenum.

Would you mind doing the same for C# ? You should be able to test
quite easily for backwards compatibility using the 'make
partialcheck-java-test-suite' and compare the output before and
after... there are currently plenty of enum tests for these.

William