Re: [Swig-devel] Swig, inheritance and PHP

[Olly B. <ol...@su...>]

On 2009-09-14, David Fletcher <fr...@tu...> wrote:
> It's easiest to explain the issue with an example and I'll use the
> google libkml project I've been working on.  Here's a subset of the
> classes defined in various .i files:
>
> 	class Feature {
> 		...
> 	  bool	has_name() const;
> 		...
> 	}

Presumably has_name() is public?

> 	class Container : public class Feature { ... }
>
> 	class Folder : public class Container { ... }
>
> Note: the has_name() function is only defined in the Feature class,
> not the derived classes.
>
> If, in PHP, an object of the Folder class is obtained, PHP can't find
> or resolve the has_name() function.  For example:
>
> 	$folder = $factory->CreateFolder();
> 	if ($folder->has_name())  # <--- this fails
> 	  ...

Oddly, there's almost exactly this situation in the Xapian PHP wrappers,
except that the factory is a function, not a method, and there's only
one level of inheritance.  And that works...

> (I can walk through the actual code if that's helpful, but I didn't
> want to bore everyone with the details until asked.)

A self-contained minimal reproducer would be useful.

> I suppose my question really is: Shouldn't PHP Resources be dropped in
> favor of using the PHP object interface?  And a follow-on question is:
> has anyone been engaged in doing this?

The resources are inherited from the PHP4 support (and it was much
easier to keep using them while we supported both).

We could create the objects entirely in C/C++ code using the API.  The
PHP4 wrapping did this on top of resources, but that doesn't work with
PHP5 AIUI, and I couldn't find any documentation for the new approach.

But there now is some documentation of the API we'd need to use (written
since I looked before), so it's mostly that nobody has expressed
interest in putting in the work required.  Miklos suggested it might be
a suitable GSoC project idea for next year.

The current approach of having a PHP class wrapper around flat functions
is more like the approach SWIG uses for Python (and most other languages
I believe), so consistency is perhaps an slight argument for the current
approach.  But I imagine creating the classes from C/C++ would be faster
which would be an argument for changing.

Cheers,
    Olly