aboutsummaryrefslogtreecommitdiff
path: root/TODO
blob: 8cc941f5616d58a026c3092958b27f38e9aaace0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
SWIG TO-DO

Release: SWIG-1.3.18    (Late Feb??? 2003)
-----------------------------------------------------------------------------

****    = High Priority
***     = Implement if possible.
**      = Will implement if time.
*       = Implement if bored (or deemed necessary).

defer   = Implement in 1.3.17

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.

[DONE] Merge "in" and "ignore" typemaps into a single "in" typemap.
       This would solve a variety of subtle problems with multiple
       argument typemaps and other typemap code.   I propose to merge
       the typemaps by making "ignore" a typemap attribute.
       For example:

           %typemap(in,ignore="1") int *OUTPUT (int temp) {
                $1 = &temp;
           }

       This merging makes a lot of sense because "in" and "ignore"
       typemaps both deal with input argument handling and they are
       meant to be mutually exclusive of each other.   By unifying
       into a single typemap, you fix the mutual exclusion problem
       (since there is only one typemap).  I also think it makes
       more sense to think of an "ignored" argument as a input value
       property.

       Update: Matthias proposes a generalization in which the
       number of input arguments could be specified.  For example:

           %typemap(in,numinputs="0") int *OUTPUT (int temp) {
                $1 = &temp;
           }

       This seems to be a better solution.


****   Implement "throws" typemaps for all of the target languages.
       Partly implemented for Tcl, Perl, Python, Ruby, Java.

***    Add attributes to the %feature directive. Something like:

       %feature("except", throws="OutOfMemoryException")

***    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 { ... }

***    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 ... };

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

[DONE] Modify smart pointer handling to properly handle inheritance.  For
       example:

            %ignore Foo;

            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.

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

**     Add a warning for uninstantiated templates.  For example, if a function
       using a template type, but that type hasn't been instantiated using
       %template.

*      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 would really only be for completeness.

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.

***    Move the Source/Modules1.1 directory into the Source/Modules directory
       and deprecate Modules1.1.

Library
-------

****   Add more support for the C++ standard library.  std::complex and other
       core datatypes.   Refine support for STL vector.   Add more STL objects.

****   Continue to expand the set of recognized typemaps.

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

****   Add Ruby support for Mark Rose's polymorphism code.

****   Investigate the new object allocation framework that has been
       implemented for Ruby 1.8 and determine what (if anything) needs
       to be changed for the wrapper code generated by SWIG. For background
       see ruby-talk messages 23358 and 38856 (and related threads).

***    Add support for keyword arguments (by collecting them in a hash?).

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

*      Add some special directives to automatically rename declarations to
       or from CamelCase.

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

**     Vararg typemaps

[DONE] $javaconst(1) option for enums - so that no JNI call is necessary to 
       get the value of the enum.

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

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

**     Rename slot setters from CLASS-SLOT-set to CLASS-SLOT-set!
       to match Scheme convention for naming of mutators.

**     Support keyword args.

**     Support GOOPS shadow classes.

**     Support garbage collection.  Here is a possible design:

       -- %new annotation decides whether a pointer smob can be gc'ed.

       -- New smob type `swig-gc'; instances created with
          SWIG_Guile_MakeCollectablePtr.  %new versions of the pointer
          typemaps use this function rather than SWIG_Guile_MakePtr.

       -- New typemaps "destructor", "gcmarker".  Their values are taken
          as identifiers for functions taking one argument: a pointer to
          the object to be destroyed, or whose SCM-valued subobjects are
          to be marked.  After creating the pointer equivalence table,
          we iterate again over the remembered pointer types, emitting
          code that puts the functions into our type table.  No
          additional functions are generated.

       -- The default for all pointer types would be:
          %typemap(destructor) SWIGPOINTER * "free";
	  (or "delete" for C++)

       -- A special annotation, e.g. FREED, can be attached to the
          arguments of destructor functions, so that explicitly freed
          structs won't be collected by the GC again. Like this:

	   %typemap(argout) SWIGPOINTER *FREED {
	     smob-tag($source) = swig; /* non-gc */
	     smob-data($source) = NULL;
	   }
	   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.  (Maybe
       GOOPS metaclasses?)

**     Maybe communicate the type system between object modules via Scheme
       variables, rather than a shared object.

**     Provide a clean way to construct type predicates.

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

****   Extending SWIG (and internals).

***    Perl, Python, Tcl modules.

***    add section for Perl module support for operator overloading

**     Add section on WAD.

Other
-----

****   Bring Tiger's .NET/CLR module online.

****   Learn more wicked Jazz chords.