[Mapserver-users] Options to try experimental Perl/Python/Ruby mapscript changes in CVS

[Sean Gillies]

Hi,

Work is underway to bring the PHP-Mapscript and SWIG mapscript APIs more
in-line.  PHP-Mapscript does some things in a better way than does the
SWIG mapscript and we aim to bring as many of these as possible to the
Perl/Python/Ruby modules.  Some of these would break the existing API
and so we are enabling the new features under the control of a SWIG
preprocessor symbol NEXT_GENERATION_API.  Why the long ugly name?  To
motivate us to make this stuff standard as soon as possible :)

You will have to run SWIG on your interface file like this

    swig -lang -shadow -DNEXT_GENERATION_API ...

to get the new features.  The nightly build process will continue as it
has and will *not* enable the next generation API features.

What is in the next generation api?  The getShape method of layerObj has
been rewritten to return a shapeObj rather than MS_SUCCESS/MS_FAILURE,
and has the order of shapeindex and tileindex parameters switched so
that the less used tileindex parameter may be optional.  Future features
in the next generation api will be along these lines, making sure all
get* methods return objects, reordering parameters and such.

Separate from these new features are optional renaming of mapscript 
classes.
Running SWIG like

    swig -lang -shadow -DNEXT_GENERATION_NAMES ...

results in classes that are renamed from mapObj, outputFormatObj, etc to
Map, OutputFormat, and so on.  The next generation names are capitalized
"camel case" whereas the standard names are not well distinguished from
class method names.  We're all using object-oriented languages, so the 
"Obj"
suffix is redundant.  It is also a cross-language convention (see CPAN 
and
the Python standard library) that package and class names be 
capitalized.
The new names are a bit controversial, but I really do feel that forming
class names in a way distinctly different from class attributes and
methods improves API clarity.  The ongoing documentation of the 
development
mapscript will continue to use the standard class names.

Python users can readily upgrade existing code to use the next 
generation
class names

     import mapscript     # with next generation names

     # Rename the next generation classes for use with older code
     mapscript.mapObj = mapscript.Map

     # Continue with older code
     mapobj = mapscript.mapObj('foo.map')
     ...

I am pretty sure Ruby users can do something similar.  Perl?  I'm not 
sure.

There are new issues in Bugzilla concerning these experimental features

next generation api:     
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=586
next generation names:   
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=587

cheers,
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies