From ad48922bccd4ec8231e09e34aedb2870fe10a838 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Matthias=20K=C3=B6ppe?= Date: Thu, 27 Nov 2003 13:32:20 +0000 Subject: [PATCH] *** empty log message *** git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@5426 626c5289-ae23-0410-ae9c-e8d60b6d4f22 --- SWIG/TODO | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/SWIG/TODO b/SWIG/TODO index 833a32c84..b3e180faf 100644 --- a/SWIG/TODO +++ b/SWIG/TODO @@ -420,6 +420,37 @@ Guile ** 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 --------