Repository navigation
Consider builder pattern #3
Description
Taking a cue from this conversation, have you considered a builder pattern to better organize task definition? Configuration patterns like this are sensitive to change (as I'm sure you've seen with grunt).
For example:
// using node-task to generate a compliant module
var Task = require('task');
module.exports = new Task('name')
.description('This task does absolutely nothing.')
.version('0.1.0')
.setup(function(){...})
.exec(function(){...});Abstracting the api for task creation and task querying will offer (the potential) for greater future compatibilty by not having to manage backwards compat off a single, catch-all configuration method (or for each consumer if supporting the object literal syntax)
Activity
paulmillr commentedon Feb 8, 2013
I don’t see how this improves compatibility. Could you explain with some example?
tkellen commentedon Feb 8, 2013
I'm also confused how this would improve future compatibility? I'm not totally opposed to this pattern, but I don't see how chaining and putting values in parens is an improvement (except visual preference for some) over defining properties.
Also, the main goal of node-task is to define a sensible and stable API that all task runners can utilize. While this repo currently includes a task builder, anyone could write their own using whatever definition syntax makes them happy. As long as the resulting object presents a compatible API, it will work.
paulmillr commentedon Feb 8, 2013
+100, just don’t break stable and well-defined APIs, do big switch to alternative API in the future. It is always a pain.
jsoverson commentedon Feb 8, 2013
If the configuration is sufficiently flexible enough, then it's not much of an issue and another task builder can handle this configuration.
If the API is the goal, should the definition have its own repository so discussion is centralized around the right topic and not confused with implementing code of builders and/or consumers?
tkellen commentedon Feb 8, 2013
It probably should, yes. It's co-mingled right now because I needed to work with an actual implementation when I was building this to see how things worked.