[Geowanking] Geospatial Library Catalog

[Andy Armstrong]

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