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- [email protected]
415.558.1610
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
