Re: [Swig-devel] php smartptr, swig_cast_info

[David F. <fr...@tu...>]

Hi William,

>>>>> "WSF" == William S Fulton <William> writes:

[ snip ]

WSF> So far we have these approaches:

WSF> 1) operator -> overloading where extra classes are generated (default 
WSF> handling)
WSF> 2) boost::shared_ptr handling using %types and %feature("smartptr")
WSF> 3) boost::intrusive_ptr handling using similar techniques.

WSF> Which of these does yours follow and if it is different, what is
WSF> deficient with the approaches already taken?

I'm adding boost::intrusive_ptr support --- no. 3 in your list --- for
perl and for PHP.  The approach that I'm using requires only small
changes to the C++ code; most of the changes are in a few .i or .swg
files.  Here's the list of changed files:

    frodo@panther$ svn status -q
    M      Source/Modules/php.cxx
    M      Lib/php/php.swg
    M      Lib/php/typemaps.i
    M      Lib/php/std_string.i
    M      Lib/php/phprun.swg
    M      Lib/perl5/perlrun.swg

A change was needed to perl5.cxx, but this was made quite a while back
and has already been committed (by you).  I don't remember what was
involved, but only a few lines were affected.

There are two changes that need to be made to php.cxx:

	1. The code that generates destructors always tried to destroy
	   the "core" type.  I've modified the code to retrieve the
	   type from the "feature:smartptr" attribute, if provided,
	   and use this, instead.

	2. I'm still making this change: the code that generates
	   pointer return values was mostly correct in that it would
	   make use of typemaps and, thus, generate the intrusive_ptr
	   type.  But, the auxilliary PHP code that was generated ---
	   this code takes resource objects and converts them to class
	   objects --- isn't capable enough.  It didn't work with
	   typemaps (eg, smartptr) types correctly.

	   My plan is to have the generated C/C++ create the resource
	   objects (as today) and, when appropriate, create the class
	   objects, too.  This will make the generated PHP auxilliary
	   files smaller and simpler.  It's easier to make sure that
	   typemaps are dealt with correctly.  Instead of generating
	   this PHP code:

		public function get_coordinates_array_at($index) {
			$r=Coordinates_get_coordinates_array_at($this->_cPtr,$index);
			if (is_resource($r)) {
				$c=substr(get_resource_type($r), (strpos(get_resource_type($r), '__') ? strpos(get_resource_type($r), '__') + 2 : 3));
				if (!class_exists($c)) {
					return new Vec3($r);
				}
				return new $c($r);
			}
			return $r;
		}

	   You'd wind up with PHP code that looks like this:

		public function get_coordinates_array_at($index) {
			return Coordinates_get_coordinates_array_at($this->_cPtr,$index);
		}



As for the .i/.swg files, here's a brief overview of the changes:

	3. The I've added support for multi-value returns for PHP.
	   This is needed for argout typemaps.

	4. I've improved support for std::string within PHP:
		- INPUT, OUTPUT and INOUT are now handled
		- string pointers and reference support is more
		  complete

	5. For perl, a change was made a while back to the trunk to
	   add ConvertPtrAndOwn() support.  Then, a change was
	   recommended by Olly to always assert a variable.  I don't
	   agree with this change so I've made a change back to my
	   local repository.  Once I have time I'll write up a more
	   complete explanation.

There some files that don't show up in the list above: the generic
intrusive_ptr.i file; the language-specific intrusive_ptr.i files.

(By the way, I made a recommendation a while back to change the name
of the language-specific intrusive_ptr.i files so that the language
appears in the file name (eg, perl_intrusive_ptr.i).  This was vetoed.
I think this should be reconsidered: it would simplify support and
lessen confusion.)

	6. The generic intrusive_ptr.i file is simpler and smaller.

	7. The java/intrusive_ptr.i and python/intrusive_ptr.i files
	   are modified slightly (because of #6).  I've also added
	   comments which, I'm hoping, will make it easier for people
	   to understand how this works.

	8. The perl/intrusive_ptr.i and php/intrusive_ptr.i files are
	   new.  They mimic the python/intrusive_ptr.i file, mostly,
	   as the java/intrusive_ptr.i file is quite a bit different.
	   Again, I've tried to document the various typemaps to make
	   it easier to understand and to support.

I can send any of these files by private email if you want.  My plan
was to add all of these to the tracker ... once I have the PHP code
finally done and once I've created tests for the new code.

-- 
David Fletcher				Tuscany Design Automation, Inc.
dav...@tu...		3030 S. College Ave.
720-207-9278				Ft. Collins, CO 80525 USA