From 50801b9c79fc0bc33575afde3df0e54df97d826d Mon Sep 17 00:00:00 2001 From: William S Fulton Date: Tue, 14 Dec 2004 23:13:04 +0000 Subject: [PATCH] bah. mistakenly added so removing git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@6882 626c5289-ae23-0410-ae9c-e8d60b6d4f22 --- swigweb/TODO | 395 --------------------------------------------------- 1 file changed, 395 deletions(-) delete mode 100644 swigweb/TODO diff --git a/swigweb/TODO b/swigweb/TODO deleted file mode 100644 index adb76c1b1..000000000 --- a/swigweb/TODO +++ /dev/null @@ -1,395 +0,0 @@ -SWIG TO-DO - -Release: SWIG-1.3.24 - -$Header$ ------------------------------------------------------------------------------ - -**** = High Priority -*** = Implement if possible. -** = Will implement if time. -* = Implement if bored (or deemed necessary). - -defer = Implement in next version - -CORE: - -**** Add support for nested classes. The type system should be -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: - - struct Foo { - struct { - int x,y; - } z; - }; - - This is one of the last remaining "hard" problems in the SWIG - core, but it is important that we solve it. - -**** Typemap environments. Stay tuned. - -*** "Nested" typemaps. The basic idea is similar to allowing one to - use $descriptor(T) for any T, rather than just $descriptor - for the type currently being typemapped. - - In short (ha!), given a previously defined typemap: - - %typemap(in) Foo { - // whatever it takes to initialize $1 from $input - } - - it would be possible to inline its code inside another typemap. - While the syntax is still to be defined, the use would be - along the lines of: - - template class vector { - %typemap(in) vector { - ... - for (int i=0; i $typemap(in, input=x) - ( int FIRST = foo, double SECOND = bar ); - - The advantage of this syntax would be that the formal - arguments (int FIRST, double SECOND) are close to the - actual arguments (foo, bar). - - Comment by beazley - - $typemap(in, input=x) int = foo; - - is a little bit hard to parse in terms of variable substitution. - I'm considering something like this: - - $typemap(in,1=int foo, input=x) - -*** Implement $fail special variable substitution in wrappers. Used - to properly transfer control out of a wrapper function while - reclaiming resources. - -*** Better targeting of output typemaps. For example: - It is not possible to target an output typemap for function - Foo::func() and not Bar::func(). Output typemaps need to support - syntax something along the lines of: - - %typemap(out) int *Foo::func { ... } - - Currently only globals functions can be targeted, like so: - - %typemap(out) int *func { ... } - -*** Rewrite declaration annotation to better unify %rename and related - directives. Add a selector mechanism that allows specific parse tree - nodes to be identified. For example: - - %feature("foo", nodetype="class") Foo { ... some code ... }; - - 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 - management. Continue to consolidate SWIG directives to %feature. - -*** Bring Aquinas' contract/assertion checking code online. - -*** Add more intelligent information related to object ownership. - SWIG should be able to automatically strip ownership from - 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. ] - -** Restoration of the documentation system. - -** Restoration of Objective-C support. - -** Unification of symbol tables and type system scopes. In a sense - they capture the same information so it is not necessary to have - both. The existence of two symbol management systems is mostly - historical. - -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. - -Library -------- - -**** Add more support for the C++ standard library. std::complex and other - core datatypes. Refine support for STL vector. Add more STL objects. - - [ Partially finished for Python. ] - -**** Continue to expand the set of recognized typemaps. - -Windows -------- - -All language modules --------------------- - -Python ------- - -*** Ability to wrap certain classes as Python built-in types. - -Perl ----- - -**** Rewrite runtime pointer type checking to better integrate - shadow classes. Creation of shadow classes should be done - in C instead of Perl. This will fix a number of problems - related to typemaps and reduce the amount of Perl wrapper code. - -**** Create tests for existing support for operator overloading - -Tcl ---- - -Ruby ----- - -**** The "Resource Management in Proxies" section of the "SWIG and C++" - chapter discusses how proxies' ownership of their associated C++ - object can change, and the use of the special disown() and - acquire() methods to change this ownership status. Need to - address this for Ruby as well. - -*** Add support for keyword arguments (by collecting them in a hash?). - -* Add some special directives to automatically rename declarations to - or from CamelCase. - -Java ----- - - -C# --- - -*** 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++. - -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 " notation. - See: abstract_inherit_wrap.cpptest - -** 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 ------ - -** Maybe rename slot setters from CLASS-SLOT-set to CLASS-SLOT-set! - to match Scheme convention for naming of mutators. - -** Support keyword args. - -** Director Support! - -** Cleaner handling of multiple values. - Use a typemap keyword argument "numoutputs" of "out" and - "argout" to indicate how many values are returned. - -** Make SWIG's types first-class by using a separate smob type for - 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. This would remove the - need of a shared SWIG runtime library. - -** Provide a clean way to construct type predicates. - -** In GOOPS mode, maybe make overloaded functions methods. - -** Increase the safety of destructor functions. John Lenz suggests: - - I think the best way of doing this would be to use %feature to mark - which classes allow for "normal" smobs to be deleted explicitly. - - We separate pointers into two classes, those that can be deleted from - scheme and those that can't. The pointers that can be deleted use the - smob and those that can not be deleted use the - smob. A user can specify which type of each object they want - with %newobject and the CONSUMED typemap. - - By default, the exported destructor will only accept - smobs, because by definition, collectable-swig smobs are those that can - be deleted from scheme. This allows for the user to implement - protection. In the interface file, the user has complete control over - which objects can and can not be deleted, and can guarantee that - objects that should not be deleted can not be deleted, and that objects - that should eventually be deleted will be garbage collected. - - This protection can then be overridden with a %feature directive, - something like - - %feature("guile_allow_destroy_all","1") Foo::~Foo; - - I don't know what word we want to use, guile_allow_destroy_all is kinda - bad. This feature would then allow for a smob to be - deleted by passing it to the destructor. This would allow users to - maintain the protection on other classes, only manually overriding the - protection on the classes that need it. - - -Mzscheme --------- - -** Port list-vector.i and pointer-in-out.i from Guile. - -** Add shadow class support for the Swindle system. - -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. - -Common Lisp ------------ - -* Random thoughts by mkoeppe on supporting Common Lisp implementations: - - There are many different Foreign Function Interfaces (FFI) for - the various CL implementations. Probably SWIG should interface - to UFFI, a least-common-denominator FFI that supports many - implementations. - - Via the s-expression SWIG module we can export SWIG's parse - tree and import it into CL. It remains to check if all - relevant information is dumped (for instance, the type - information). Experimental code is available to generate - low-level UFFI declarations from this parse tree. - - However, for wrapping C++, we also need to create C wrappers - because most FFIs cannot directly import C++. A CL SWIG module - could be exporting both these wrappers and UFFI declarations. - I have experimental code (not checked in yet) that does this. - - This is fine for generating low-level wrappers. But how do we - support user typemaps (like converting lists and vectors to C - arrays on input)? We have to generate Lisp code that does the - conversion and then calls the low-level wrapper. If we - generate Lisp code, it should be beautiful and readable. - Therefore, we need at least a Lisp pretty printer. A Lisp - pretty printer works best when the Lisp program is represented - not as text but as Lisp data. Moreover, typemap writers will - feel very much constrained by SWIG's capabilities for - generating wrapper code, when compared to writing Lisp macros. - Thus we would need half a re-implementation of Lisp in SWIG to - make users happy. - - The solution could be the following: - -** Build a SWIG library (again) and load it into a Common Lisp - implementation. - - The FFI declarations could be written manually, or this could - be bootstrapped via the s-expression module or the primitive - UFFI wrappers. This should be easy because SWIG's API is quite - simple. - - The embedded SWIG would be driven by a CL program. High-level - typemaps would be written as Lisp programs that generate Lisp - code. - -Ocaml ------ -** I've been working with my camlp4 module and type information - from the compiler. When I'm done, the user will have access - to type inference when writing code, when the inference is - unambiguous. This allows the user to write x = _foo 1.0 - instead of x = get_float (_foo (C_float 1.0)). It's not as - easy as it sounds, because O'caml doesn't keep type information - at run time, and doesn't really have a mechanism for doing what - I need. However, it's possible to write a preprocessor that - inserts correct type info at compile time. - - That having been said, the program must compile for type info - to be available, so I need to attend to a lot of details; The - program must compile both with and without type augmentation. - -Xml ---- - - -Documentation -------------- - -**** Extending SWIG (and internals). - -*** Perl, Python, Tcl modules. - -*** add section for Perl module support for operator overloading - -** Add section on WAD. - -Other ------ - -***** Learn more wicked Jazz chords. - (in progress) -