[Xapian-devel] PHP Latest

[Olly Betts]

I think I've now done everything we need for wrapping Xapian, apart from
handling method names which clash with PHP reserved words (e.g empty, clone).
However, for a general SWIG solution a few more things are still missing.

Here's the latest version:

http://www.oligarchy.co.uk/xapian/patches/swig-php-gen-oo-wrappers9.patch
http://www.oligarchy.co.uk/xapian/patches/xapian9.phps
http://www.oligarchy.co.uk/xapian/patches/xapian_wrap9.cc

On Fri, Apr 21, 2006 at 04:45:45AM +0100, Olly Betts wrote:
> TODO:
> 
> * Use parameter names instead of $argN.

Done - we now build parameters by joining the different possible names
in overloaded variants with "_or_".  An unnamed parameter is called
"argN" (e.g. "int foo(int)" -> "function foo($arg0)").

> * Handle a parameter called $this gracefully.
> * Check a duplicate parameter name is handled OK, and fix if not.

Both done, and so is $r - any parameter name which clashes with a
previous name just gets underscores appended until it no longer clashes.

> * Handle any non-covariant class return value without swig_wrap_return.

Done.

> * Perhaps handle covariant class return by checking against the known
>   list of possible types (if not we need to generate a portable version
>   of swig_wrap_return() which could well be more work...)

Done - a covariant return now looks like:

        if (!is_resource($r)) return $r;
        switch (get_resource_type($r)) {
        case "_p_Xapian__WritableDatabase": return new XapianWritableDatabase($r);
        default: return new XapianDatabase($r);
        }
 
> * Profile to see if switch is slower than "if ... else ..." for
>   overloads with only two possible parameter counts.

Daniel checked this, and there's no detectable difference.

> * For switch (func_num_args()) we can omit cases for which there's
>   no overload which allows that many parameters (e.g. for Foo(int a) and
>   Foo(int a, int b, int c, ..., int z) we can only validly get 1 or 26
>   arguments - other counts are invalid, so we could handle them together
>   with "default".  Not sure this is worth the effort though...

Done.

I've also eliminated the SwigXapianBase class (which wasn't actually used
for anything any more).

Class functions no longer have "public" in front (since it's the default
and PHP4 doesn't support it, though the generated code doesn't yet work
with PHP4 for other reasons).

Constants are now in the appropriate PHP class.

And default parameter values are checked to make sure they're PHP constants
(currently I reject any string, since some adjustments are needed and Xapian
doesn't require this).

Cheers,
    Olly