[Mapserver-dev] Next Generation MapScript API

[sgillies at frii.com]

> Frank Warmerdam wrote:
>> I have hadn't been thinking of changing the PHP side, though in the
longer term
>> we do need to think about how to keep the PHP reasonably in sync with the
>> SWIG based MapScript implementations.
>
> I think that to be consistent we should always try to keep the PHP and
SWIG API's in sync and think of them this way... I think this is already
the way most of the developers think, so we should continue in that
route.
>
> This means that any change proposal that can't (or wouldn't) be applied
to both needs to be reconsidered.
>
>> I would be amendable to deferring "next generation" SWIG MapScript roll
out
>> to post-4.2 release.    Currently (as I understand it) the default is
to
>> not
>> use the next generation api stuff.
>
> The only way those changes can work for us (DM Solutions) is if there is
a compatibility mode as was suggested somewhere in this thread. DM
Solutions is probably the group with the largest amount of PHP code
relying on the current MapScript APIs, and any single function or object
change is a major issue for us.
>
> However, if major changes must happen, then I think a good timing for us
(talking for DM Solutions again) would be to make any API changes
coincide with a switch to PHP5 since some important work may be involved
in php_mapscript to take full advantage of many of PHP5's new features.
While we're at it we would probably attempt a switch to SWIG-PHP as
well.
>
> Um... I guess if we know we'll make major changes anyway when we go to
PHP5, and we know that we may be going with SWIG at that time, then it's
not that much of an issue if SWIG-MapScript takes a different route than
PHP MapScript today... but I would still urge you to wait until after
the 4.2 release, and possibly even after a 4.4 release if we plan to do
one in June.
>
> My 0.02$
>
> Daniel

Daniel,

I agree with you, and want to work together on the API.  But ... :) when
you write "keep the PHP and SWIG modules in synch", you sort of gloss over
the fact that these modules are actually only about 85% (in my rough
estimation) exact intersection in their APIs.  Some of this is because PHP
mapscript uses get/set methods to set object
attributes and SWIG mapscript uses get for other purposes, some of this is
because of PHP methods that return arrays rather than single objects or
SWIG methods that return indexes of objects rather than the object.

IMO, the final 15% cannot be bridged without a significant refactor of
the mapscript API that will impact both PHP and SWIG mapscript users.
We can't go forward anymore without taking a step or two backwards.
And if we undertake the work to really merge the APIs, I'd suggest that
time be spent to generally improve them.

It doesn't look really good for SWIG and PHP.  I saw a post
on the SWIG list that said the PHP code has been abandoned by its
developers and that no PHP5 work has been started.  It may be that
if DM Solutions wanted to go the SWIG route, you'd have to get seriously
involved in SWIG, much more than I have had to be.  Python is probably
the best supported SWIG language, followed by Java.

Sean