On Jan 24, 2011, at 5:37 AM, Roel Vanhout wrote:

> For the last couple of weeks I've been chipping away at making php
> bindings for mapnik.

Yay!


> Which brings me to one of the reasons to write this mail; if there is
> anyone interested in using mapnik from php and has wide experience
> with php, in particular with api design for php libraries, I could use
> someone to brainstorm about the api with. Although I consider myself
> an experieced php developer, I do not have much of a 'feel' for what
> is natural in api design in php, or at least not the extent I do for
> C++. I also do not have experience with the mapnik python bindings, so
> I don't know the approach there; if it follows the C++ api closely or
> tries to fit in with common python idioms. So if anyone is interested
> in discussing this, and/or writing documentation and test cases in
> advance to flesh out the design, please let me know.

I use PHP *a lot* so I'd love to participate in this. I've seen a few styles of 
PHP C bindings, mostly in one of two camps: OOP and functions. An example of 
the former would be Memcached and an example of the latter would be GD:

        http://www.php.net/manual/en/class.memcached.php
        http://www.php.net/manual/en/function.imagecreate.php

Personally, I think PHP's lurch toward object-orientedness over the past few 
years is misguided, and I'm a big fan of the namespaceless, all-function 
modules like GD that work by passing resources around. For mapnik, it would 
make sense to have a single kind of resource: a map object. Everything else, 
like rules, styles, layers, etc., could be represented with simple associative 
arrays and plain values.

-mike.

----------------------------------------------------------------
michal migurski- m...@stamen.com
                 415.558.1610



_______________________________________________
Mapnik-users mailing list
Mapnik-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/mapnik-users

Reply via email to