Re: [Swig-devel] SWIG 3 - Perl improvements

[Robert S. <ta...@tr...>]

On Mon, Oct 21, 2013 at 08:54:48PM +0100, William S Fulton wrote:
> On 20/10/13 21:08, Robert Stone wrote:
> >On Tue, Oct 15, 2013 at 12:32:44PM -0700, Robert Stone wrote:
> >>On Tue, Oct 15, 2013 at 07:31:56AM +0100, William S Fulton wrote:
> >>>Is there much more to do or is it ready now for merging?
> >>
> >>         There is not much remaining.  I am working on expanding the
> >>Perl5 director docs, and that process has me looking at things pretty
> >>closely.  I'm not confident about how director destructors are currently
> >>handled, but I should be able to clean it up in the next couple of days.
> >
> >         This took longer than I'd hoped, but I think destructors are in
> >far better shape now.  Unfortunately, it comes at the cost of breaking
> >an aspect of reverse compatibility.  Some of SWIGs perl5 examples showed
> >calling "$obj->DESTROY()" as the proper way to release objects.  I
> >haven't been able to make this use pattern play well with normal object
> >cleanup now that directors can be involved.
> >
> >         With more work, I might be able to make an explicit DESTROY call
> >the only way to release a SWIG wrapped object, but it strikes me as the
> >wrong thing to do.  I am pretty sure the Perl community would find this
> >just as awkward as if a C++ library suggested you run "obj->~Obj()" to
> >release objects instead of "delete obj".
> >
> The problem is if this was the shown to be a normal way to delete
> objects, then a lot of code is going to break. I can see the
> documentation also has examples like this. The approach taken might
> be a relic of before proxy objects were implemented. In fact does
> -noproxy still work? I don't think we have any tests for -noproxy.
> 
> >         I think the branch is ready for merge unless more work is needed
> >to suppress that incompatibility.
> 
> Breaking the way objects are destroyed is far from a corner case and
> pretty fundamental, I feel we should add this back in. Sorry! Is
> there something special about DESTROY, can it not be added as an
> extra legacy wrapper method around destructors, perhaps via a
> feature?

        I have been testing -noproxy mode, but nowhere near as heavily
as the default mode.  This is mainly because I don't know how to add
test-suite entries that run swig with alternate command line options.
Things work there, but the implicit argument to static member functions
feels awkward in that mode since in that mode SWIG is not emitting a
class for you, and doesn't do anything you can see with that argument
either.  I suspect I do have some additional reverse compatibility
problems with some of the other command line options, particularly
-compat and -nocppcast; I haven't been testing against those.

        I will try to work on this further.  It probably makes sense to
investigate not trying to unify the director proxy system with the
existing one.  If I can do that, retaining complete reverse
compatibility should be trivial.

                                                -Robert