[Xapian-devel] PHP Latest

[Sam Liddicott]

Olly Betts wrote:

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

>  
>
>>{
>>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?
>  
>
It is where it would 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?
>
>  
>
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?

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

Sam

>Cheers,
>    Olly
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tartarus.org/pipermail/xapian-devel/attachments/20060421/68086276/attachment.htm