[Xapian-devel] PHP Latest

[Sam Liddicott]

Olly Betts wrote:

>OK, another update:
>
>http://www.oligarchy.co.uk/xapian/patches/swig-php-gen-oo-wrappers8.patch
>http://www.oligarchy.co.uk/xapian/patches/xapian8.phps
>http://www.oligarchy.co.uk/xapian/patches/xapian_wrap8.cc
>
>I've eliminated get_func_args/call_user_func_array in favour of using
>default parameters and switching on func_num_args().
>
>Non-overloaded functions/methods which return a class now just check if
>it's a resource and wrap it in the appropriate class if it is.
>  
>
This could also be done in the C;

{
SWIG_SetPointerZval(return_value, (void *)result, 
SWIGTYPE_p_Xapian__PostingIterator, 1);
}
/* Wrap this return value */
{
/* ALTERNATIVE Constructor, make an object wrapper */
zval *obj, *_cPtr;
MAKE_STD_ZVAL(obj);
MAKE_STD_ZVAL(_cPtr);
*_cPtr = *return_value;
INIT_ZVAL(*return_value);
*return_value=*_cPtr;
}

Here I confess I don't know why we need the second block, but this 
generated code segment is where wrapping of pointers to resources takes 
place.
Here is where instead of returning the resource we wrap it again in 
another class and return that.

>And I've eliminated the special case wrapping of a resource for classes
>which have a copy constructor, since the flat wrappers do it for us
>anyway (and have been so far since there was a case error in the
>resource name I was generating a test against!)  All Xapian API classes
>have a copy constructor (sometimes implicitly) so that code has gone for
>us.
>
>  
>
Hmmm, the php resource that wraps the xapian objects is never 
duplicated, so any copying of php objects will result in the same 
resource being shared. I don't know if this matters

>Parameters are currently still only named in the "no-overloads, default
>args" case.  I notice that we need to handle the case where a parameter
>is called "$this" since we use "$this->swig_ptr".  Apart from that we're
>safe I believe (I use $r to hold the return value in some cases, but I
>think that'll be OK even if there's a parameter called $r since the
>lifetimes are disjoint).
>  
>
Only maybe, php4 still allows users to pass-by-reference in cases where 
the function was not expecting (or required) a reference, in such cases 
using $r would trash the original value.
There are uses for such behaviour, namely that explicit pass by 
reference prevents default values, and in some cases the caller may not 
be interested in extra values back.

If you:
unset($r) at the scope in which you want to re-use it, you will have 
detatched it from any passed-in reference and you can then make use of 
it as you will.

Sam

>TODO:
>
>* Use parameter names instead of $argN.
>* Handle a parameter called $this gracefully.
>* Check a duplicate parameter name is handled OK, and fix if not.
>* Handle any non-covariant class return value without swig_wrap_return.
>* 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...)
>* Profile to see if switch is slower than "if ... else ..." for
>  overloads with only two possible parameter counts.
>* 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...
>
>Cheers,
>    Olly
>
>_______________________________________________
>Xapian-devel mailing list
>Xapian-devel at lists.xapian.org
>http://lists.xapian.org/mailman/listinfo/xapian-devel
>  
>