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@4713 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Logan Johnson 2003-04-25 21:24:44 +00:00
commit f60b413181
2 changed files with 8 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

7
SWIG/CHANGES.current
View file

@ -1,5 +1,12 @@
Version 1.3.20 (In progress) 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) 04/25/2003: ljohnson (Lyle Johnson)
[Ruby] Added the -globalmodule command-line option for the Ruby [Ruby] Added the -globalmodule command-line option for the Ruby
module, for wrapping stuff into the global module (Kernel) instead module, for wrapping stuff into the global module (Kernel) instead

20
SWIG/TODO
View file

@ -213,7 +213,7 @@ Ruby
[DONE] Add support for defining nested modules. This should work like it does [DONE] Add support for defining nested modules. This should work like it does
for the SWIG Perl module. 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 and Ruby"), Brett Williams suggested a workaround for supporting
multiple inheritance in the Ruby module. I'm quoting it here since 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 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) e.g. Derived#is_a?(Base1) would return true but Derived#is_a?(Base2)
would return false. 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 * Add some special directives to automatically rename declarations to
or from CamelCase. or from CamelCase.