<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Olly Betts wrote:
<blockquote cite="mid20060421153809.GL20016@survex.com" type="cite">
  <pre wrap="">On Fri, Apr 21, 2006 at 09:28:34AM +0100, Sam Liddicott wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Olly Betts wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">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.
      </pre>
    </blockquote>
    <pre wrap="">This could also be done in the C; [...]
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.
  </pre>
</blockquote>
True<br>
<blockquote cite="mid20060421153809.GL20016@survex.com" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">{
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;
}
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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?
  </pre>
</blockquote>
It is where it would be patched in.<br>
<blockquote cite="mid20060421153809.GL20016@survex.com" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">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
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">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-&gt;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).
      </pre>
    </blockquote>
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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?

  </pre>
</blockquote>
I didn't realise anything here was specific to php5. But doing unset()
first on parameters that we want to re-use privately is safe and is a
swig-specific fix anyway?<br>
<blockquote cite="mid20060421153809.GL20016@survex.com" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
</blockquote>
spotted!<br>
<br>
Sam<br>
<blockquote cite="mid20060421153809.GL20016@survex.com" type="cite">
  <pre wrap="">Cheers,
    Olly
  </pre>
</blockquote>
<br>
</body>
</html>