jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

1.3.22 update

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@6179 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
William S Fulton 2004-08-30 21:40:55 +00:00
commit 78604426ea
6 changed files with 88 additions and 207 deletions
Download patch file Download diff file Expand all files Collapse all files

147
SWIG/TODO
View file

@ -1,6 +1,6 @@
SWIG TO-DO
Release: SWIG-1.3.20
Release: SWIG-1.3.22
$Header$
-----------------------------------------------------------------------------
@ -31,36 +31,7 @@ defer ready to go. The primary obstacle lies in the target language
**** Typemap environments. Stay tuned.
[DONE] Merge "in" and "ignore" typemaps into a single "in" typemap.
This would solve a variety of subtle problems with multiple
argument typemaps and other typemap code. I propose to merge
the typemaps by making "ignore" a typemap attribute.
For example:
%typemap(in,ignore="1") int *OUTPUT (int temp) {
$1 = &temp;
}
This merging makes a lot of sense because "in" and "ignore"
typemaps both deal with input argument handling and they are
meant to be mutually exclusive of each other. By unifying
into a single typemap, you fix the mutual exclusion problem
(since there is only one typemap). I also think it makes
more sense to think of an "ignored" argument as a input value
property.
Update: Matthias proposes a generalization in which the
number of input arguments could be specified. For example:
%typemap(in,numinputs="0") int *OUTPUT (int temp) {
$1 = &temp;
}
This seems to be a better solution.
**** Implement "throws" typemaps for all of the target languages.
Partly implemented for Tcl, Perl, Python, Ruby, Java.
[DONE] Implement "throws" typemaps for all of the target languages.
*** "Nested" typemaps. The basic idea is similar to allowing one to
use $descriptor(T) for any T, rather than just $descriptor
@ -167,38 +138,6 @@ defer ready to go. The primary obstacle lies in the target language
[ Partially finished for Tcl/Python. ]
[DONE] Modify smart pointer handling to properly handle inheritance. For
example:
%ignore Foo;
class Foo {
public:
Blah *operator->();
};
class Bar : public Foo {
}
Bar should still allow access to Blah * through operator->().
[DONE] Virtual function optimization. If you have two classes like this:
class Foo {
public:
virtual int blah(int);
};
class Bar : public Foo {
public:
virtual int blah(int);
};
Then SWIG ought to be able to reuse the wrapper for Foo::blah as
Bar::blah. This should result in much smaller extension modules.
This feature is now enabled using the -fvirtual option.
** Restoration of the documentation system.
** Restoration of Objective-C support.
@ -223,9 +162,6 @@ Build
**** Make sure there are tests for *ALL* library files in the test-suite.
A number of files appear to be broken in SWIG-1.3.13.
[DONE] Move the Source/Modules1.1 directory into the Source/Modules directory
and deprecate Modules1.1.
Library
-------
@ -237,9 +173,6 @@ Library
Windows
-------
[DONE] Visual C++ Project files / Makefiles for building the runtime libraries.
Will require libtool mods to work under Cygwin.
All language modules
--------------------
@ -272,68 +205,11 @@ Ruby
acquire() methods to change this ownership status. Need to
address this for Ruby as well.
[DONE] Investigate the new object allocation framework that has been
implemented for Ruby 1.8 and determine what (if anything) needs
to be changed for the wrapper code generated by SWIG. For background
see ruby-talk messages 23358 and 38856 (and related threads).
*** Add support for keyword arguments (by collecting them in a hash?).
[DONE] Add support for defining nested modules. This should work like it does
for the SWIG Perl module.
[DONE] In a post to the SWIG users' mailing list (June 5: "Multiple Inheritance
and Ruby"), Brett Williams suggested a workaround for supporting
multiple inheritance in the Ruby module. I'm quoting it here since
the idea may be best implemented at the core level for reuse by other
language modules that have limited support for MI:
"""
While it makes for longer generated wrapper code, you can easily
generate wrappers as Ruby methods on the derived class in these cases,
i.e.:
class Base1;
class Base2;
class Derived : public Base1, public Base2;
class OtherDerived : public Base2;
This would mean that for class Derived, the methods for Base2 would be
generated as methods on class Derived as opposed to a superclass. For
class OtherDerived, things work as normal, and any other derived class
from Base2 would still work as they currently are, unless other derived
classes also use MI. The exception and extra wrapper generation would
only kick in with the use of multiple inheritance where the base class
information is available to SWIG.
The feature could be turned on and off, and doesn't have to be default
if necessary.
I was under the impression that the Tcl module, until a few releases ago,
did all inheritance this way (generating wrappers for superclass methods
in all derived classes). It does bloat the wrapper code, but in this case
it would only be causing more bloat in cases where the alternative is
no support.
What is missing with this? Hmmmm... if Base2 implements a method that is
overridden by Derived, then you could not get at Base2::Method() via the
super keyword... what else am I missing? Again, the alternative is no
support for MI at all unless you want to get fancy with mixins. I'm not
sure how good of an idea that is or even if it is workable.
"""
Another problem (which we can't really get around anyways) is that
basic inheritance relationships wouldn't be true at the Ruby level,
e.g. Derived#is_a?(Base1) would return true but Derived#is_a?(Base2)
would return false.
* Add some special directives to automatically rename declarations to
or from CamelCase.
[DONE] Consider adding a switch to define everything in the global (Kernel)
module instead of nested in a user-defined module, but only if
it comes up.
Java
----
@ -341,28 +217,19 @@ Java
at present. An overridden method for each default argument could be
generated thereby enabling one to call methods with default arguments.
[DONE] Implement idea from Dave Dribin email to the swig mailing list, 2 April 2003,
where the global enums and constants are placed in an interface so that they
can be implemented by other Java classes. This will allow improved syntax when
referring to the enums/constants:
int foo = enumname;
instead of
int foo = ModuleName.enumname;
C#
--
[DONE] Need a way to throw a C# exception from the PINVOKE C/C++ code.
[DONE] The correct override/virtual keywords not always emitted for polymorphic
methods. It currently works with 'virtual' is specified in a derived
C++ class function. A polymorphic method need not specify 'virtual' in C++.
[DONE] Wrap C/C++ enums with C# enums, currently they are wrapped with a C# int.
**** Implement director support for C# so that virtual methods work seemlessly
when mixing C# and C++ code.
**** Fix exception handling. Currently memory leaks occur when a C# exception
is thrown from C/C++.
**** Default argument support - see Java above.
PHP
---