Hi Alex, On Fri, Jan 18, 2013 at 08:26:10PM +0100, Alexander Bernauer wrote:
I thought it would make sense to use these names for ease of reference. Given this, would you still prefer them being grouped in separate modules?
Yes, I still think that having separate modules can be beneficial, also for the ease of reference.
Gdbmi.Commands is not the only module that depends on the GDB version.
I thought of putting all of your modules under the version indicating module.
GDB/MI is in general still evolving and GDB's compliance with the documentation keeps on changing on all levels. So I would have to maintain all hgdbmi modules for each GDB version. Do you think this makes sense and is worth the effort?
At the current level of development, the version indicating module might be unnecessary and overhead, but you also don't have to support multiple GDB versions. It's just a more explicit way of telling your user for which GDB version the binding should work. You can reuse most of your code for several GDB versions. Supposed you've implemented the GDB 7.4 bindings and now would like to support a new command in GDB 7.5 and all other commands behave still in the same way as in version 7.4. module Gdbmi.V7_5.Commands (module Gdbmi.V7_4.Commands, newCommand) where newCommand = ... Greetings, Daniel