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

*** empty log message ***

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@4713 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Logan Johnson 2003-04-25 21:24:44 +00:00
commit 9e945cb779
2 changed files with 8 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

7
CHANGES.current
View file

@ -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

20
TODO
View file

@ -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.