[Xapian-discuss] PHP Bindings

[Olly Betts]

On Wed, Sep 08, 2004 at 10:40:30AM +0100, James Aylett wrote:
> On Wed, Sep 08, 2004 at 02:32:16AM +0100, Olly Betts wrote:
> > There's a more elaborate version here which takes care of the extension
> > already being loaded and also works on Windows (though probably not on
> > some other UNIX platforms - they don't all use .so for shared objects):
> > 
> > http://www.php.net/manual/en/function.dl.php
> 
> I think the examples should assume the invocation will load the .so,
> personally.

OK, but we should document how to make sure it's loaded then, otherwise
users face a potential frustration trying to get even the examples to
run.

Alternatively, we could try to load the extension if it's not already
loaded.

I'm planning to add an automated "smoke test" to each bindings too, so
"make check" will run a simple script for each which at least ensures
that the extension can be loaded and (say) stemming a word works.

I think we also want two modes of installation - currently we carefully
try to detect the standard directories to install stuff into for each
language.  However if you're not root, this means you need to install
your own copy of the interpreter, mess with libtool's abstraction and
poke around in .libs, or mess with DESTDIR when installing.  If you
could force everything to be installed under --prefix, then most
languages allow you to load extensions from non-standard locations,
and ideally we want to document the required runes ("make check" will
need to use them too).

> > We should really add a "Xapian_" prefix to everything - as it is we
> > rather pollute the namespace, and prefixing like this is the norm for
> > php (e.g.  MySQL is wrapped as mysql_*).  Anyone know how to do this
> > with SWIG?  For Tcl, swig has a -prefix option, but not for php4.
> 
> I was unable to find a way of doing it, but ISTR Sam saying something
> about it.

Hmm, he said: "that would still need updates to the php swig module."

http://lists.tartarus.org/pipermail/xapian-discuss/2004-May/000054.html

Probably quite easy updates though.  Perhaps I should take a look.

> > Also, why do we rename empty methods to is_empty?  PHP4 has a built in
> > function called empty, but since we prefix methods with the class name,
> > MSet::empty() would become MSet_empty() anyway.
> >
> > We also rename empty to is_empty for the Python bindings, but again
> > for no reason I can see: Python's Queue class has an empty() method, so
> > it seems unlikely we can't...
> 
> Pass. Looks like I made that change, when I made the Python bindings
> work with Py2.2 ... no idea why. Feel free to change it, I guess ...

Actually, it looks like Sam first renamed an empty() method to
is_empty(), for OmESet (the first wrapped class to have one).  I guess
you (or others) probably copied this renaming when wrapping other
classes.

http://cvs.xapian.org/xapian/xapian-core/bindings/swig/Attic/xapian.i.diff?r1=1.6&r2=1.7

Sadly there's no check-in comment for this change and it was 2.5 years
ago, so we can probably only guess at why now.  Two changes earlier Sam
had wrapped OmQuery::is_empty(), so I wonder if the rename was for
consistency.

> > And a bonus question: why does the C++ API have Query::is_empty()?
> > I think for consistency we should probably add Query::empty() and
> > deprecate Query::is_empty()...
> 
> +1. Although empty() sounds like a verb for any collections (Database,
> particularly). is_empty() is clearly a test. That may not be terribly
> important though.

I'd not noticed that.

In C++ at least, empty() will definitely read as a test not an action
because STL containers use it (which is why MSet does).  Query isn't an
STL compatible container, but it does hold things and could become a
container one day perhaps.

Cheers,
    Olly