From 9e945cb779e2be3fea2921d4af463a45fe7becb8 Mon Sep 17 00:00:00 2001
From: Logan Johnson <ljohnson@users.sourceforge.net>
Date: Fri, 25 Apr 2003 21:24:44 +0000
Subject: [PATCH] *** empty log message ***

git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@4713 626c5289-ae23-0410-ae9c-e8d60b6d4f22
---
 CHANGES.current |  7 +++++++
 TODO            | 20 +-------------------
 2 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/CHANGES.current b/CHANGES.current
index 05c0db1ce..4fa63cb38 100644
--- a/CHANGES.current
+++ b/CHANGES.current
@@ -1,5 +1,12 @@
 Version 1.3.20 (In progress)
 ============================
+04/25/2003: ljohnson (Lyle Johnson)
+            [Ruby] Added a kind of limited support for multiple inheritance,
+            activated using the -minherit command-line option. I've also updated
+            the "C++ Inheritance" section of the Ruby documentation to discuss
+            how this works, and its limitations. Also also modified the minherit.i
+            test case to run against this.
+
 04/25/2003: ljohnson (Lyle Johnson)
             [Ruby] Added the -globalmodule command-line option for the Ruby
             module, for wrapping stuff into the global module (Kernel) instead
diff --git a/TODO b/TODO
index b683e089c..308bb25f5 100644
--- a/TODO
+++ b/TODO
@@ -213,7 +213,7 @@ Ruby
 [DONE] Add support for defining nested modules. This should work like it does
        for the SWIG Perl module.
 
-**     In a post to the SWIG users' mailing list (June 5: "Multiple Inheritance
+[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
@@ -258,24 +258,6 @@ Ruby
        e.g. Derived#is_a?(Base1) would return true but Derived#is_a?(Base2)
        would return false.
 
-**     A related suggestion from Brett Williams (and perhaps an alternative
-       to the previously described workaround for MI) is to provide a
-       variant of the %extend directive that allows you to pretend that these
-       functions should be treated as if they were in the class definition,
-       i.e.:
-
-	   %define ADD_ART_PROP_METHODS(classname)
-	   %extend classname {
-	     void AddArtProperty(const String &key, const String &val);
-	     String GetArtProperty(const String &key) const;
-	     const PropertyVector *GetArtProperties() const;
-	   };
-	   %enddef
-
-       As written, SWIG would expect you to have provided functions with
-       names classname_AddArtProperty(), etc. somewhere else in the wrapper
-       code. We'd prefer that it somehow knew to call the function directly.
-
 *      Add some special directives to automatically rename declarations to
        or from CamelCase.