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

update to 1.3.15

Browse source 
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@3837 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Dave Beazley 2002-09-10 20:01:45 +00:00
commit a8c883d4ae
8 changed files with 386 additions and 174 deletions
Download patch file Download diff file Expand all files Collapse all files

301
SWIG/TODO
View file

@ -1,6 +1,6 @@
SWIG TO-DO
Release: SWIG-1.3.14 (Late July, 2002)
Release: SWIG-1.3.15 (Late August, 2002)
-----------------------------------------------------------------------------
**** = High Priority
@ -8,10 +8,12 @@ Release: SWIG-1.3.14 (Late July, 2002)
** = Will implement if time.
* = Implement if bored (or deemed necessary).
defer = Implement in 1.3.16
CORE:
**** Add support for nested classes. The type system should be
ready to go. The primary obstacle lies in the target language
defer ready to go. The primary obstacle lies in the target language
modules (which were never programmed with nested classes in
mind). There are also issues with nested C structures. For
example:
@ -25,64 +27,70 @@ CORE:
This is one of the last remaining "hard" problems in the SWIG
core, but it is important that we solve it.
**** Better modularization of language modules and a minor redesign
of the very high-level API. Issues:
[DONE] Refinement of the overloading dispatch rules. If you have two
classes like this:
- Language modules should be created by a factory function
with C linkage. For example:
class Foo {
};
Language *PYTHON_init() {
return new PYTHON();
}
class Bar : public Foo {
};
swigmain.cxx should then be modified to only use the factory
functions when bringing a module into existence. This
decouples main() from the implementation of each language
module---and eliminates the need to have header files
for each module.
and two overloaded methods:
Placing C linkage on the initialization function provides
support for eventual dynamic loading of SWIG modules--it
establishes a well-known symbol name that can be used in
conjunction with the dynamic loader.
void spam(Foo *f);
void spam(Bar *b);
- Perhaps the module system would be simplified by having
all code located in a single file instead of a separate
header file and a separate implementation file.
SWIG should make sure that the derived class version is checked
first.
- Does anyone inherit from existing modules?
[DONE] Refinement of using directives. For example:
*** Support for overloaded functions. It is probably possible to
add some kind of support for this. Overloading has been supported
internally for quite some time---the warning messages are there
simply as a stop-gap measure (since no language modules support
overloading). We would keep the the existing %rename support.
namespace foo {
int blah(int);
}
*** Support for smart-pointers and proxies. This is primarily to
support classes that implement the -> operator and which are used
to dispatch on another class. I think it would be cool if
SWIG could automatically detect and handle this case. For example,
if you had this:
namespace bar {
double blah(double);
}
class FooProxy {
...
Foo *operator->();
...
};
using foo::blah;
using bar::blah;
Perhaps SWIG could automagically locate Foo and arrange for its
methods to be associated with FooProxy. This is really not too
bad. The proxy methods could be wrapped normally with only
one minor modification in the wrapper code. If the class Foo had
a method "bar" it would be invoked as this, through the proxy:
Currently, SWIG reports an error (redefined symbol). Instead, it should be
silent.
FooProxy *arg1; // Object pointer (to proxy)
(*arg1)->bar();
^
extra "*" added here.
It's not entirely clear what should happen in terms of overloading. Currently,
the two functions can't be combined into an overloaded method (they are
in separate namespaces and the functions don't quite combine like that).
One could generate wrappers for the using declarations. However, this
could generate a conflict (if both the namespace and non-namespace version
are wrapped).
I think automatic wrapping of methods would be much nicer than
requiring the use of a special directive.
[DONE] Modify exception handling code not to apply to attribute access. Should
reduce the amount of wrapper code substantially when a global exception
handler is used.
**** Typemap environments. Stay tuned.
[DONE] Implement option to print dependencies.
**** Implement "throw" typemaps for all of the target languages.
[DONE] If a wrapper can't be generated to a function/method for some
reason, provide a flag that prevents that function/method from
appearing the dispatch function.
If a language module sets the "error" attribute of a node, it is
not included in the dispatch function.
[DONE] Investigate the enhancement of exception handling to match against exceptions
specified with throw specifiers.
*** Add attributes to the %feature directive. Something like:
%feature("except", throws="OutOfMemoryException")
*** Rewrite declaration annotation to better unify %rename and related
directives. Add a selector mechanism that allows specific parse tree
@ -90,6 +98,13 @@ CORE:
%feature("foo", nodetype="class") Foo { ... some code ... };
Also desirable for the Java module to specify the classes to go in the
throw clause:
%feature("except", throws="OutOfMemoryException") Foo {
... code which throws the OutOfMemoryException ...
};
Consider use of wildcards. Namespace/nested scope support in
%feature is currently weak. It works, but is fragile. Consider
an implementation that is better integrated with symbol table
@ -102,6 +117,37 @@ CORE:
objects when they are assigned to pointer variables and structure
members as well as stored in a container (i.e., an array of pointers).
[ Partially finished for Tcl/Python. ]
*** Modify smart pointer handling to properly handle inheritance. For
example:
class Foo {
public:
Blah *operator->();
};
class Bar : public Foo {
}
Bar should still allow access to Blah * through operator->().
** 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.
** Restoration of the documentation system.
** Restoration of Objective-C support.
@ -111,11 +157,37 @@ CORE:
both. The existence of two symbol management systems is mostly
historical.
** Add a warning for uninstantiated templates. For example, if a function
using a template type, but that type hasn't been instantiated using
%template.
[DONE] Fix build problems on 64-bit platforms. We need to replace
NULL by (char *) NULL in most modules.
Defined NIL as (char *) NULL. Used that in most modules--especially
with functions like Printv().
* Fix template partial specialization matching rules. SWIG does not
implement the proper C++ type deduction rules, but it does handle
the most common cases. This is likely to be hard and implementing
it is really only for completeness.
it would really only be for completeness.
Build
-----
[DONE] Fix Python Windows examples.
**** Upgrade libtool to a more recent version. Might fix linking on OS-X
but should definitely help on Cygwin.
**** 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.
*** Move the Source/Modules1.1 directory into the Source/Modules directory and
deprecate Modules1.1.
* Upgrade autoconf? This will definitely help for Windows. The later the
version the better.
Library
-------
@ -124,11 +196,14 @@ Library
**** Continue to expand the set of recognized typemaps.
All language modules
--------------------
[DONE] Convert use of char * to String *. Suggest using Replaceall()
instead of Replace(..., DOH_REPLACE_ANY);
Python
------
**** Support for Python-2.2 style classes.
**** Ability to wrap certain classes as Python built-in types.
Perl
@ -152,32 +227,107 @@ Ruby
to be changed for the wrapper code generated by SWIG. For background
see ruby-talk messages 23358 and 38856 (and related threads).
** 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.
** 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.
* 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
----
**** Improved pointer handling to take advantage of Java's static type
checking. Currently all pointers are a Java long and these could
be changed to use a Java class wrapper.
**** Better support for global variables and functions when using proxy
classes. They could be put into a global proxy class to improve on
current syntax:
A a = new A(module.global_function(b.getCPtrB()), true);
to use something like:
A a = Globals.global_function(b);
*** Implement function overloading.
*** Implement replacements for the deprecation of the %pragma directive.
* Consider using typemaps for proxy class code generation.
* Consider using typemaps for proxy class code generation. [partially
implemented]
PHP
---
** When returning wrapped objects via alternate constructors if that
pointer value already exists "out there" as a resource we should
use the same resource, we can't have multiple ref-counted resources
mapping to the same object in case it gets twice destroyed. And check
if ref count destroying is even working, see smart_pointer_rename
* Work out how classes without even inherited constructors should
interact with the php "new <class>" notation.
See: abstract_inherit_wrap.cpptest
[DONE] Work out when we can but shouldn't dispose of objects because the
creator will. See %newobject in the docs. Works automatically for
constructors and return-by-value.
[DONE] Got class properties to work, and global vars to work both ways
with _set and _get accessors
** Look at pass by point and passby ref,
Make sometype** to be auto allocated
Make sometype& and sometype* to be autoallocated IF THEY ARE NOT
ALREADY swigtype wrapped.
* Overloading, callbacks, really review to see what else is missed
Guile
-----
@ -219,7 +369,8 @@ Guile
void free_foo(struct foo *FREED);
** Make SWIG's types first-class by using a separate smob type for
SWIG type descriptors; enable reflection on types.
SWIG type descriptors; enable reflection on types. (Maybe
GOOPS metaclasses?)
** Maybe communicate the type system between object modules via Scheme
variables, rather than a shared object.
@ -227,6 +378,18 @@ Guile
Mzscheme
--------
Pike
----
* Decide how to handle global variables (probably using something
like the Python module's cvar). Affects Examples/pike/simple.
* Decide how to handle static class member functions and member
variables.
* Should investigate the possibility of generating .cmod files
in addition to straight C/C++ code for extensions.
Documentation
-------------
@ -242,3 +405,7 @@ Other
-----
**** Bring Tiger's .NET/CLR module online.
**** Learn more wicked Jazz chords.