On 30 Aug 2006, at 22:01, Andrew Turner wrote:
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".
OK :)
That certainly seems /more/ reasonable. I suspect that the burden of
cataloguing the options that are supposed to be provided and what
their precise semantics are and the downstream burden that authors
will be expected to comply with those specifications will mean that
we just end up with less code out there.
Bear in mind that the options really need to have the exact same
semantics across multiple languages if we're saying "these are the
options and this is what they do irrespective of the language you're
using". If we have identically named options that are merely rather
similar it's worse than just having ad hoc options - it'd be actively
misleading as opposed to passively confusing :)
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.
But presumably there are precedents for file parsers in Python
culture just as there are in Perl culture - isn't a Python developer
more likely to expect the GPX parser to work a bit like the Python
XML parser or the Python HTML parser than the Perl GPX parser? He/she
presumably has no knowledge of Perl.
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.
OK - I see a glimmer here :)
But I also see the spectre of modules with complex interfaces and
many options just so they can be the same as another module in
another language. I'm struggling to see modules that have
sufficiently complex interfaces that there's benefit in standardising
across multiple languages as a good thing.
In practice a GPX parser probably just needs to be told what to
parse. If you need to, say, split tracks or synthesise missing
elements - or whatever - that should really be something you do to
the data after parsing.
I suppose in a nutshell what I'm saying is that having enough options
that they need to be standardised in the way you describe seems
antithetical to clean interface design.
> 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. :)
I can certainly see the benefit of the idea that was discussed
somewhere ^^^ up there of a matrix with languages across the top,
tasks down the side and links to the code that addresses the task for
each language at the intersections - that's a great idea not least
because it makes it easy to identify missing functionality for each
language.
I remain less convinced about the advisability of trying to
standardise interfaces across multiple languages :)
--
Andy Armstrong, hexten.net
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
