.prototype

[nick-thompson]

None of our constructors use .prototype, and I'm not really sure why. For one, this is a pretty big performance hit for any application using several databases (i.e. our test suite?). For two, there's a lot of poorly written, nested functions within constructors for the sake of closed variables that makes reading/understanding the files so much harder than it needs to be (sorry if I'm being harsh, but the LevelPouch constructor in our leveldb adapter is... the entire file).

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

[daleharvey]

The main reason for using the module pattern is that I find it less readable to read code constantly refering to this, and especially since we use a lot of async api's internally leading to a lot of var self = this (or .bind(this)).

Its slightly less performant but only if you are recreating the object a lot of time which is a fairly special case for our tests, not much reason for users code to do that.

If theres a proposal thats cleaner than the alternative then down for checking it out, in theory I would expect a full switch to .prototype to be less readable though

[calvinmetcalf]

I agree with you @nick-thompson, though actually doing it is the hard part. @daleharvey while this. can be confusing, at the moment our solution is not much better. for instance use of this would allow us to further modulerize the code e.g. break up lib/setup.js and also the adapters could inherit from Pouch.adapter.

It actually might not be that hard, changing this line to var api = this; and then deleting this line would do it for http adapters

[nick-thompson]

I'll take a stab at rewriting the leveldb adapter to conform to this proposal and we can carry on this discussion in the context of actual code, sound good? I'll probably get to it some time tomorrow or Tuesday. Also, I'm working on writing up some thoughts about how we can minimize the amount of code an adapter actually requires, so perhaps I'll include those thoughts in my example rewrite and we can hash both things out at once.

[calvinmetcalf]

fyi the map reduce plugin uses prototype

[enquora]

Agree with @nick-thompson on the problem of grokking code given multiple levels of nested callbacks in the absence of any design documents at all, especially statecharts. This seems certain to negatively affect implementation of correct behaviour.

[daleharvey]

Done