Re: PHP binding via SWIG

[Paul Colby <pa...@colby.id.au>]

On Wed, Jan 26, 2011 at 10:29 PM, Gordon Sim <gs...@redhat.com> wrote:
> The aim for the messaging API is that it should feel natural to developers
> experienced in the particular language while retaining appropriate
> conceptual consistency across languages.

Luckily for me, PHP is very similar to C/C++, so it's actually quite
an easy / natural fit :)

> We have a wrapped .NET API for example that also adapts the API to .NET
> naming conventions etc. Are there any PHP specific adjustments or naming
> conventions we should adhere to that would make the API more palatable to
> the general PHP audience? The use of the Variant class in the c++ API seems
> like an area that would ideally be slicker for scripting languages (note: I
> know virtually nothing about PHP, I'm afraid!)

Yes, indeed, the Variant class would not seem very "natural" in PHP.
PHP provides an array that can act like both an indexed array (a la
Variant::VAR_LIST) and an associative array (a la Variant::VAR_MAP),
and can contain any native type (including more arrays).  So, in
effect, PHP has native support for hierarchical data structures like
the Variant class provides.  So it would make most sense to write a
Variant <-> PHP-native-types typemap (that's probably the only major
piece I've yet to start on... seems fairly straight-forward though).

It might also make sense to re-work some of the Duration class' static
members (eg Duration::SECOND)... I'm starting to work on that now.

> Another objective is that the API in any language would allow for an
> alternate implementation. For example someone at some stage may decide a
> particular language benefits from a native implementation, or we may find
> that a C core gives us wider reach than C++ or whatever. We want to ensure
> that we can evolve the implementation if needed without needlessly breaking
> the API that applications are using.

With the exception of some possible method renaming (see another email
I sent earlier today), and the Variant / Duration type-mapping,  the
PHP binding should be almost 100% identical to the C++ API, which as
mentioned above, is a good natural fit for PHP, so this binding should
not cause any significant issues with future API evolution (fingers
crossed) :)

> It would be great to get examples of using PHP as well. Matching the set
> that the other clients have (particularly helloworld, drain and spout) would
> be ideal.

Will do :)

helloworld is already done (except for one Duration parameter), and
looks very natural for PHP :)

will sort out drain & spout soon, as well as map_sender/receiver (very
good examples for the PHP equivalent of Variant).

> I think a separate JIRA would be best. Another one was created recently for
> perl (https://issues.apache.org/jira/browse/QPID-3009).

Done  - https://issues.apache.org/jira/browse/QPID-3027 :)

> Your contribution needs to be granted to the ASF before it can be committed.
> Assuming you haven't sent in a signed ICLA, you can do this by checking the
> box when you attach the patch to a JIRA.

Will do :)

> Thanks again for using and contributing to Qpid! Great to have you on board,

It's my pleasure!  I'm just glad I can give something back without
having to grok the entire Qpid code-base - that would take some
dedication! ;)

Paul.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org