[Geowanking] Geospatial Library Catalog

[Andrew Turner]

On 8/30/06, Andy Armstrong <andy at hexten.net> wrote:
> If you're using a language that allows you to avoid long lists of
> positional arguments you're usually well advised to do so - so
> standardising function signatures across multiple languages seems
> like a bit of a retrograde step.
>
> > Distance ([lat1, lon1, <alt1>], [lat2, lon2, <alt2>], model)
>
> Yes, but in Java my points are instances of net.hexten.geo.Point
> (perhaps) and in Perl they might be references to hashes like this:

I didn't mean to imply they would have the exact "function
signatures", or anything. Pull back just a little bit further. All
your examples had a common set of options, regardless of *how* they're
passed in/set, its that there is a common set of options that all the
interfaces provide. Think Behavior-Driven-Development (to use a
phrase-of-the-day). The interface is saying "what all can this thing
do"?

That way, you prevent the one interface from defining "split every #
seconds", but then another interface using "point array size".

>
> And who benefits if we force all these different languages to use the
> same function signatures? The majority of developers don't language-
> hop all that often so the benefit of having a clear, well designed
> interface that's native to whatever language they're using greatly
> outweighs any benefit that accrues from being able to call functions
> the same way in different languages.

The purpose being that the entire "functionality/language matrix" can
be covered. Say someone writes a Perl module to parse GPX, but there
wasn't a Python one yet. Seems best to say: I'll use the Perl
"interface" (remember, abstractly) and write it in Python. I can look
at the GPX reference that the Perl module points to.

I can also use the same "tests" that the perl module verified itself
against. I want to pass the same GPX file & options through my Python
module and see that I get the same results and feel more confident
that I can trust my module.

> > ...etc...
> >
> > But maybe that is too specific across languages. At the very least
> > defining general problem s/patterns, features, and referenced
> > standards.
>
> Examples please :)
>

I would think picking up, say, "Mapping Hacks" and seeing that as a
large set of useful patterns and desired behaviors. Also look at all
the current Perl modules that you're gathering, as well as the
Ruby/Python/*C* libraries that exist as the desired set of tools.

Conglomerated, they help all the languages/projects see what users are
trying to do and then pulling that together so it's a single-point of
reference for my programming needs. :)


-- 
Andrew Turner
ajturner at highearthorbit.com        42.4266N x 83.4931W
http://highearthorbit.com              Northville, Michigan, USA