node-task / spec

A specification for javascript tasks.
MIT License
153 stars 2 forks source link

Consider builder pattern #3

Closed jsoverson closed 11 years ago

jsoverson commented 11 years ago

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)

paulmillr commented 11 years ago

I don’t see how this improves compatibility. Could you explain with some example?

tkellen commented 11 years ago

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 commented 11 years ago

+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 commented 11 years ago

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 commented 11 years ago

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.