On 09/18/2010 04:43 AM, Howard Butler wrote:
On Sep 17, 2010, at 7:12 AM, Ari Jolma wrote:
Folks,
I added binding to VSIStatL (my idea is to start using ReadDir from GDAL and I
need to know if something is a file or a directory).
Why not use the more natural (to you the Perl programmer) facilities your
language provides for determining this? In my opinion, this adds a lot binding
complexity for very little gain.
The Windows support in Perl is sadly not very good in this respect
(readdir for unicode file names). It can be done but using GDAL
functions seems to me a good idea as they should soon support unicode
filenames in Windows and also because I'd be feeding those names back to
GDAL anyway to open the files.
I guess if we could trust GDAL to call CPLError always we could simply use one
RETURN_NONE typemap and not three.
Unfortunately, it's too late for that :/
I'm not quite sure I understand why.
I don't disagree with any of the above situational information regarding
typemaps and what's necessary to write bindings for VSIStatL. I just disagree
that we need public, calcified, never-to-be-changed-ever-again bindings for a
compatibility layer that users can already get from their language's
facilities. With help. And fewer bugs ;)
Most other VSI*L functions were in the bindings already. With a comment:
"It is just for some testing stuff.", however.
I usually have a big trouble understanding what goes on in the bindings
as they are a sort of meta code. And when things have been named
confusingly (maybe not confusingly in the beginning but after some
changes they have become confusing) it just adds to the pain. I guess
this was the first time I really did understand how this set of bindings
work - at least I think so.
IMHO README.typemaps seems outdated and not even always used. For example:
%typemap(out) (retStringAndCPLFree*) should be added and
Python uses
out (char **out_ppsz_and_free)
instead of
out (char **CSL)
which is mentioned in the README.typemaps
Cheers,
Ari
Howard
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
