[Xapian-devel] PHP Latest

[Olly Betts]

On Fri, Apr 21, 2006 at 09:28:34AM +0100, Sam Liddicott wrote:
> Olly Betts wrote:
> >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; [...]

So far I've been trying to preserve the flat function interface to work
as before.  The little tweak I made (to allow it to accept a class wrapping
a resource where a resource is wanted) still allows current usage to work.

But it's harder to see how to wrap returned resources in classes while
still keeping the flat function interface working as before.

> {
> 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;
> }

I don't see where the XapianPostingIterator class is created.  Or is
this just the part of the code where this would need to be patched in?

> 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

It doesn't matter for most of Xapian's classes, since they're just
reference counted handles so we're just using PHP's reference counting
instead.

MSetIterator and ESetIterator won't currently copy properly, but they're
bidirectional_iterators, so copying the C++ object will do what we want.

There's a problem with some of the iterators (the ones which are
input_iterators, which is everything except MSetIterator and
ESetIterator) in that we *can't* easily make a clean copy.  Once
you call "++" on an input_iterator any existing copies become invalid.
If we want to support that from PHP, we'd need to write code to create
a new iterator (by calling XXX_begin() and then skip_to() for example).

It might be feasible to provide a "clone" method on those iterators
to support this - I'll take a look at that.

> >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.

I think we're squarely targetting PHP5 with these wrappers aren't we?
(You seem to imply that this feature has been removed in PHP5...)

Or is there a possibility they'll work on PHP4 too without much extra
effort?

> 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.

That's not always going to work, since we might generate:

$r = new_Database($r);

But there's another easy way to fix it which is to just check the
parameter list and pick a name for the return value which doesn't clash.

Cheers,
    Olly