[gdal-dev] Perl bindings in 2.0

[Ari Jolma]

Folks,

I don't know what's the amount of use of the Perl bindings, my feeling 
is that it is not so much since there's not so much discussion on this 
list or elsewhere. Anyway, I use them and want to develop them further. 
Version 2.0 is chance to do some improvements, so I'm trying.

Perl bindings have quite a lot of Perl code on top of what Swig spits 
out. I like to think that has happened due to the difference between 
what C/C++ is good at and what a high level dynamic language like Perl 
is good at.

I have most trouble with OGR, probably because of the new concept of 
multiple geometry fields and lots of API for definitions (field and 
feature), which I think would perhaps be best hidden away and replaced 
with hashes etc. which are easy to use in Perl.

These are the main ideas that I have and which I'm trying to use as 
guidelines for the implementation, any comments are welcome:

- Prefer named parameters to strict lists. I.e., accept hashes (or 
hashrefs) as parameters and study their contents. This especially so in 
constructors.

- Names of concepts. This is a bit hard since for example OGR itself 
uses "Field" to mean both feature attribute and the definition of a 
feature attribute. Should the new geometry fields (also, somehow spatial 
attribute sounds better) be strictly distinct from non-geometry 
(non-spatial?) fields? For example in method CreateLayer, should there 
be a named parameter Fields or Fields and Geom(etry)Fields? BTW, 
abbreviated forms "GeomField" and "Defn" seem to be a part of GDAL 
vocabulary, perhaps I should stick to them and avoid as much as possible 
"spatial", "schema", "attribute", and others (Schema is already used in 
Perl bindings).

- Prefer string constants, i.e., "Point" instead of $Geo::OGR::wkbPoint. 
This is already in the bindings but I plan to make them automatic (the 
strings are taken from the code in initialization instead of being 
hard-coded) and add more support for them, for example class methods to 
list all constants of certain kind.

- Getters and Setters. Perl has a tradition of having dual purpose 
attribute methods, which is however questioned in Damian Conway's Perl 
Best Practices. I've introduced some into the bindings as alternatives 
but am in doubt now. Swig ties attributes and makes the objects 
hash-like but I don't like, one reason is because I prefer string constants.

- Use confess instead of croak. The stack trace gives a much better 
understanding of what went wrong in this case although I usually don't 
like them. I also plan to add many more checks into the bindings to 
avoid strange failures.

- In general simple is better, for example only one name for one 
concept, but it is quite hard to come up with simple and elegant design. 
I'm afraid that the current design is neither. Maybe the goal should be 
to make simple things simple with the bindings but complex things also 
possible.

Best,

Ari