1.3.22 update

git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@6179 626c5289-ae23-0410-ae9c-e8d60b6d4f22

1 files changed, 7 insertions, 140 deletions

diff --git a/TODO b/TODO
index bcfbb0fd3..0b84c32aa 100644
--- a/TODO
+++ b/TODO
@@ -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
 ---