It's perfectly reasonable to create a pseudo-DSL of operations that are composed of functions.
Based on your description of what the dealWith...
functions do, though, I think you might want to generalize your functions more, something like:
function foo() {
tagInsert('h1', 'Text to append to h1 tag');
tagInsert('h2', 'Text to append to h2 tag');
tagInsert('h3', 'Text to append to h3 tag');
}
Now that the essence of the function has been distilled (append text to all tags of a specified type), and the variables of the function have been parameterized (the type of tag and the text to append), you could just as easily do something like:
var tags = {
'h1': {
'en': 'Hello',
'es': 'Hola',
'sr@latin': 'Zdravo'
},
'h2': {
'en': 'Goodbye',
'es': 'Adios',
'sr@latin': 'Do vidjenja'
},
'h3': {
'en': 'Green',
'es'; 'Verde',
'sr@latin': 'Zelena'
}
};
function foo(locale) {
for(var tag in tags) {
tagInsert(tag, tags[tag][locale]);
}
}
Composability of functions is greatly improved when as much about the operation you will perform is deferred until the function is actually called -- you can then use the exact same function to now not just append a fixed set of text to the tags, but to do so in whatever language the user prefers to use.
This flexibility can of course be taken to absurd lengths and you'd never get anything done, but it's good to think of your function as a set operator: what is the input to your function (declared explicitly as a variable or implicitly by accessing a global) and what operation is performed to produce the new output set?
If it doesn't take much extra effort to write the function in the generic way versus the specific case you're dealing with, then write it that way and you can re-use that function whenever you need to do a similar action but with different inputs.
Remember...
Don't take my tagInsert
definition at face value, I know barely anything about what you're actually trying to do, and maybe that generalization doesn't really make sense. The point is that you as the developer should have a better idea of what you're trying to accomplish.
If you follow Larry Wall's Virtues of a Programmer, you should be trying to minimize the amount of extra work you have to do, and your functions will reach the right degree of composability versus complexity.
Functions calling functions is the whole point of a function -- you avoid the need to rewrite it over and over again; just dividing a massive imperative declaration of actions to perform into a series of functions is not the point of a function. What are the repetitive patterns in the imperative code and how can you be as lazy as possible?