On 8/30/06, Andy Armstrong <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] 42.4266N x 83.4931W
http://highearthorbit.com Northville, Michigan, USA
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
