PHP 7.1 no longer supports calling methods with fewer parameters
than declared, so we need to generate __construct() with default
values for all but the first parameter.
Add optional moduleimport attribute to %module so that the
default module import code can be overridden. See the
"Searching for the wrapper module" documentation in Python.html.
Example:
%module(moduleimport="import _foo") foo
$module also expands to the low-level C/C++ module name, so
the following is the same as above
%module(moduleimport="import $module") foo
Issue https://github.com/swig/swig/issues/769
Previously we emitted a separate one for every wrapped function,
but typically many functions have the same number of parameters
and combinations of parameters passed by reference or not.
This change significantly reduces both the size of the generated
wrapper, and of the compiled PHP extension module (e.g. by ~6% for
the stripped extension module for Xapian's PHP7 bindings).
Leave PHP5 wrapping them as integers as this change could cause
incompatibilities.
Fixes issue https://github.com/swig/swig/issues/686 noted by Nishant
Gupta.
This is SWIG's default for every language except PHP, and now is a
good time to make this change so that once we drop PHP5 support, we'll
have the same default everywhere. It's easy to override the default
with -cppext cxx to get the PHP5 behaviour.
PHP5's C extension API has changed substantially so you need to use
-php7 to specify you want PHP7 compatible wrappers.
Fixes https://github.com/swig/swig/issues/571
It doesn't seem to be possible to have a Java collection with more than 2^31-1
items, but it is perfectly possible to have an std::vector with more elements
than that in C++, so add runtime checks verifying that we don't lose count of
elements in the Java wrappers.
Derive the class wrapping std::vector<> in Java from java.util.AbstractList<>.
This makes it possible to use it with various algorithms working with Java
collections and, maybe even more importantly, makes it possible to iterate
over the wrapped vectors using for-each loops.
This commit is based on the original patch by Volker Diels-Grabsch from
https://sourceforge.net/p/swig/patches/278/
No real changes yet, just use a C#-like macro in Java std::vector<> typemaps
too to avoid having to repeat almost exactly the same class declaration for
the general case and for the bool specialization.
The function "OutputClassMemberTable" tags methods generated
for a class so that R wrapper code supporting syntax like:
WrappedClass$VarName <- value
The comments in the function indicate that it is looking for
method names ending in "_set", but in fact it was searching for
methods ending in just "set", This was resulting in class methods
ending in set (names like GetOffset, SetOffset etc) being placed
in the wrong accessor functions and thus not being available in
the normal way.
There is probably a more appropriate way to tag the _set functions
when they are being created, which is a future step. This
patch makes the behaviour conform to the original intention.
The function "OutputClassMemberTable" tags methods generated
for a class so that R wrapper code supporting syntax like:
WrappedClass$VarName <- value
The comments in the function indicate that it is looking for
method names ending in "_set", but in fact it was searching for
methods ending in just "set", This was resulting in class methods
ending in set (names like GetOffset, SetOffset etc) being placed
in the wrong accessor functions and thus not being available in
the normal way.
There is probably a more appropriate way to tag the _set functions
when they are being created, which is a future step. This
patch makes the behaviour conform to the original intention.
