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

You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.

•

Gordon

how much should it be backward compatible?

It needs to be completely backwards compatible. People do use it as-is and will be upset if their code breaks. What about something like this:

// Normal
require("GPS").connect(Serial1, function(data) {
});
// With Handlers
require("GPS").connect(Serial1, function(data) {
}, function(data, callback) {
  // do stuff
  callback(data);
 return true; // if handled
});

So that way the module code is backwards compatible, and only needs changing to:

exports.connect = function(serial, callback, handlerFn) {
  var gps = {line:""};
  serial.on('data', function(data) {
    gps.line += data;
    var idx = gps.line.indexOf("\n");
    while (idx>=0) {
      var line = gps.line.substr(0, idx);
      gps.line = gps.line.substr(idx+1);
      if (!handlerFn || !handlerFn(line,callback)
        handleGPSLine(line, callback); 
      idx = gps.line.indexOf("\n");     
    }
    if (gps.line.length > 80)
      gps.line = gps.line.substr(-80);
  });
  return gps;
}

Not tested, but it should work.

•

allObjects in reply to @Gordon
I'm in very 'violent' agreement with the 100% backward compatibility - nothing is as annoying as trying something out of the box and it does not work... and stops working after a while.

Other comments:
1. Had something like this with third argument in my first - not posted - elaboration.
2. Do not like to have to provide 2nd argument when using extended mode.
3. Do not like the comparison inside the loop that is done over and over again.
4. Do not like the constraint that handlerFn's return value has to evaluate to true.
5. Module provides still no means to start/stop/enable/disable line handling.
6. I like very much the leanness of the basic GPS module.
7. Would like to foster more object oriented approach in building and using modules and components - already done in many places where an object is provided as a parameter and not just a function-object (even though, JS allows to stick 'things' - value and function properties - it, but that is dangerous...).
Therefore I chose to use different type(s) for 2nd argument. Type is handled only once at connect execution time. The handler object's constructions allows to reuse the existing line handling.

@Gordon, you did not mention the addition of the tag in the existing handleGPSLine() function. Would you consider the code with the addition still compatible?

Furthermore, you did not mention the renaming of the internals. Would that keep the compatibility for the people?

May be a general discussion about initial setup of modules whit very limited, exemplary functionality is worth a discussion. The questions to answer would be:
1. What is the purpose of a module?
2. Who is the audience for a module?
3. How is extensibility rated?
4. How about the module's general 'structure': Lambda or Object oriented - or both?
5. How could extensibility - particularly for GPS module - be implemented - override - addition - registration?

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

About

Espruino