From: William S F. <ws...@fu...> - 2013-12-19 07:05:17
|
On 18/12/13 02:06, Robert Stone wrote: > On Wed, Dec 18, 2013 at 12:01:05AM +0000, William S Fulton wrote: >> On 17/11/13 19:49, Robert Stone wrote: >>> On Sat, Nov 16, 2013 at 09:26:55AM +0000, William S Fulton wrote: >>>> I was thinking the Perl changes in your talby-perl5-improvements >>>> branch is similar to Python's -builtin option where the Proxy class >>>> definitions are moved from pure Perl/Python code to C. In Python, the >>>> builtin approach is better all round, but not so 100% compatible with >>>> existing code (although close). This should sound familiar! Perhaps >>>> you would like to bring in the changes from that branch and have it >>>> turned on via a similar command line switch to -builtin? That way >>>> users get to choose. >>> >>> That sounds like a good path. I'll investigate how this might >>> work out, but I don't think I'll be able to do this rapidly. >>> >> Would you like to say how long this might take? Given all the good >> things your new implementation has, it might be worth making this >> the default. I ask as I see SWIG 3 as one golden opportunity to put >> in backwards breaking default behaviour so long as a command line >> switch will restore the old behaviour. > > I've begun attempting a "-builtin" feature on top of the > "perl5-directors-minimal" branch. It is going to be more complicated > than reformatting the "talby-perl5-improvements" branch into conditional > blocks. Allowing both wrapper types to coexist for imports.multicpptest > style object sharing will require something more sophisticated than I > have now. I expect it will take at least a couple of months to > complete. I would not want something of that size to hold up a SWIG 3 > release. I think it makes the most sense to phase that feature in > more gradually. It seems quite a reasonable restriction to me that %import should work only if you have the same style wrappers, that is, the -builtin equivalent usage is the same for each invocation of SWIG. By all means only add interopability later on if someone really needs it. Would that speed things up? > >>> I hope this is a relatively safe thing to do from a reverse >>> compatibility perspective since any SWIG users have already had to code >>> around multiple destructor calls, and this is just a potential fourth >>> type of destructor invocation. Alternatively, we could have >>> ~SwigDirector_Object issue a new method call, "DESTROY_swig_director()" >>> for example. That method would not need to be idempotent, but would run >>> a bit slower and be another unique semantic not shared by either other >>> Perl objects or other SWIG languages. >> >> I don't know that I can offer much on the Perl side. Do you think >> github patch #106 should be merged now? I'm thinking that if SWIG 3 >> can contain your new wrapping approach as the default alongside the >> old implementation restored with a command line option, I don't see >> much point in having to support directors in the old wrappers if >> directors are better supported in the new wrappers. > > If you don't have strong feelings one way or another about this, > I think reusing the existing destructor is the better of the two > unfortunate options. That is what's implemented in the pull request. > > I don't think implementing "-builtin" gets significantly easier > if directors are not supported without it. It would give us a way out > of this destructor reverse compatibility corner, but that's the only > hard problem I think it would solve. > Okay, sounds like that branch ought to be pulled in then. William |