GPS Module, Extensions for handling other sentences, and u-blox NEO-6M GPS receiver

Well, your method with the object as the second argument seems good, but I'd remove includesDefaultLineHandler and would just always add lineHandler as a field in the gps structure instead...

I don't think renaming internal things would cause problems - they'll probably just be minified anyway. I'd try not to use long variable/function names though (while still trying to keep them informative and readable).

In terms of modules:

• They need to provide a simple way to access the device in question
  
• The audience is 95% of users, with extensibility where it can be added without much overhead. If you know what you're doing you can always just modify the existing module, but if the module is so focussed on extensibility that nobody can understand it, I think it's failed.
  
• Can you give an example of what you'd consider a 'lambda-oriented structure?'
  
  

Just to clear up my thinking here, if given the following choices:

1. Write clear, simple code that is easy to understand and modify, but doesn't do everything.
   
2. Write complicated but extensible code, and then document it extensively so that people can extend it without touching the original code.
   
   

I think the first option is the right one for Espruino.

Espruino straddles a difficult line - it's trying to be easy to use, but it is a microcontroller with very limited storage. I don't think we should waste that storage on functionality that most people won't use when they pull in the module.

About the addition of the tag: Yes, it'd be compatible - but I don't think you should add it. If you're extending the GPS module yourself, why can't you just add it if you need it? Otherwise for everyone else it's just wasting their memory.