Koa: Automatic delegation

[PlasmaPower]

This was discussed over at tj/node-delegates#14 and we decided to merge the feature then discuss it's use here. It would replace this with this:

delegate.auto(proto, require('./request'), 'request');
delegate.auto(proto, require('./response'), 'response');

delegate(proto, 'request')
  .method('get')
  .method('is')
  .getter('header')
  .getter('headers')
  .getter('socket');

delegate(proto, 'response')
  .access('body')
  .access('length')
  .access('type');

There are some conflicts, but we can keep the manual delegators for them as shown above. Since __defineGetter__ (and defineSetter) set the configurable property to true, they can be overriden. This means we can automatically delegate most of the properties, and manually delegate what we need to override.

Note that the response manual delegation isn't necessary since the second delegate.auto overrides the first one, but I think in conflicts it should be manually specified.

One problem I didn't think of is toJSON and inspect, both of which have implementations in request, response, and context. The context implementation is of course the wanted end result. We could manually define it afterwords, out of the class, although that would a bit hacky.

[jonathanong]

what's the pros and cons with this? just making delegation easier from a maintenance perspective?

[PlasmaPower]

Pros:

• We don't need a long list of properties at the end of context
• There's a good chance someone forgets to add something to the list

Cons:

• You have to remember to delegate something if it's in both request and response
• toJSON and inspect would have to be put after the delegation (or made into a function getter) as they are shared by context, request, and response

[tj]

IMO it's still looking for problems we don't really have. We've probably spent a total of ~1m maintaining that list

[fengmk2]

It's not conflicts, and the list can tell me which property is request or response. If change to auto, it will become very conflicts.

[PlasmaPower]

Ok, I've been convinced that this is a bad idea for this project where you have multiple sources. I'm closing this.

[juliangruber]

Closing :P