> I'm beginning to wonder if "module" is even a useful term. It's has so many definitions!
and moving in to "Harmony" (ES6).
on that note, i just dawned on me that the best way to define a module in our communication and documentation is to look at how the general JS community defines it, especially considering the ES6 module syntax. it would be a bad idea for us to create a definition
that is in conflict with the community's definition.
> how about the approach of "one object per file" instead?
i see this as an anti-pattern when declared as a rule to follow. if a single file happens to only need one object in order to fulfill it's needs, that's fine. but the approach of only one object per file will lead to code bloat (extra module definitions),
file bloat (where do we draw the line between 1 object per file and 1 line of code for an object?)
thinking about C#, when I declare an interface and that interface exposes events, I don't create a separate file for each of the events. I include the event definition in the same file as the interface that exposes it.
thinking about Backbone, when I declare a model and collection I don't create separate files for them. I put the model and collection definition in the same file because they belong together. they are directly related and don't make sense without each other.
also, a model and collection definition are often 1 line of code each. it doesn't make much sense to create a new file with a new module definition, for 1 line of code.
on the flip side of that, though, if a single file is becoming too large to understand as a whole, the code should be split out in to multiple files where it makes sense. if a collection is moving toward a hundred lines of code and it's model is moving toward
a hundred lines of code, it will be easier to read and understand the code if they are in separate files.
> Your goals for a "module" nicely map across to a SOLID object.
these principles are largely the guiding principles i use in OO development (in any language). there are hundreds if not thousands of ways to use these principles of course :)
if anyone's interested in these a little more, i wrote an article on using them in C# a few years ago: http://www.code-magazine.com/article.aspx?quickid=1001061