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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
