Err, I'm not sure I agree. We're asking where do we put this option. That's an api question, not just a let's get this patch out question. Putting it in writeHead is not only a stop gap, but it encourages people to continue using writeHead, which we plan to deprecate and discourage. And then we'll still have to answer this question. So why not answer it now using some forethought?
I totally get what you were going for, but it makes no practical sense to say we shouldn't consider real future roadmap plans. :Marco On Monday, February 13, 2012 10:59:41 AM UTC-8, Mikeal Rogers wrote: > > we can cross that bridge when we come to it. > > IMO, patches against master should be made against master without regard > for future plans for re-writes. It's the job of the re-writer to make all > the tests pass so if your change goes in with a test it'll still work after > the re-write. > > -Mikeal > > On Feb 13, 2012, at February 13, 201210:49 AM, Marco Rogers wrote: > > > Well there's a separate plan being discussed right now to upgrade the > API to ServerResponse anyway. writeHead is going to be deprecated, so > that's not the best place to put it. But I do agree we should minimize > unnecessary properties on res. It would be nice to have a pseudo standard > way of specifying options across node. I haven't put any thought into it > yet. But one thing I like is just using an options hash. It's not just for > functions you know :) > > > > res.options.shouldSendDate = true. > > > > This way we can add whatever we want and the chance of collision is > minimized. Of course options is a fairly common name. That's why it might > be a good idea to come up with some kind of convention. People know enough > not to name a function "on" or close" these days. > > > > :Marco > >
