ES6 classes

[brodybits]

would be better than setting prototype functions, as part of new major release (#20)

I would personally favor a more functional approach, should be possible to make it more functional in a followup stage.

[breautek]

I think an OO approach would better, and I'll explain the rationale:

• Project appears to be already fairly OO (that is you have a method that returns something an instance of an object, in which you can call methods on)

• Regardless of the paradigm chosen, holding and managing state will be required (the project data). In a functional approach, this is usually done by either by passing some kind of context object around to functions, or having a function with data encapsulated via a closure, where dynamically allocated methods can have access to (and often return itself so that you can chain methods). I don't really see this very extendable.

  The OO approach, which doesn't need to be complicated, that is I don't think we don't need builders or any other fancy design patterns. We just need a class that can be instantiated to encapsulate the project data and provide methods to manipulate the data, which like a functional approach can be changed by simply returning the instance, if desired.

• For unit testing purposes, it makes it easier to spy on as the jasmine spyOn feature expects an object, and a string as the member function spy on.

• If we make a move to TypeScript, (which I would also favour eventually) it's easier to manage a single class type rather than series of function types, and having to expose an internal state type. Every function will still have a type declared naturally when authoring a class signature, but the consuming applications/libraries does not need to explicitly import all of these function types.