I'm just as guilty as anyone about using __proto__.  It's here today and
works in node.  Even APIs and features that are standard may go away some
time.  I just try to find other solutions when I can since people get up in
arms about using non-standard features.

I think this use case is a good reason for mutable prototypes to stay in
the language.  How else can you insert prototype methods in just some
instances without manually copying all the properties on every request?  At
the same time I understand how mutable prototypes can cause implementation
problems and security issues.

Anyway, kudos on the library.  I like it!

I see that you're bundling some middleware with the library.  There are
pros and cons to this approach.  With connect I bundled them in the same
repo and npm package, with stack I made them separate.  All I can say is
keep it lean because everything you bundle will be wrong for someone
eventually.  When I maintained connect, there was no end of effort trying
to please everyone when they had wildly different use cases and
requirements.

On Thu, Apr 12, 2012 at 2:34 PM, Mathias Buus <mathiasb...@gmail.com> wrote:

> You are completely right. I see a lot of other modules mutating __proto__
> though like express and socket.io so hopefully v8 will continue to
> support it.
>
> On 12/04/2012, at 21.19, Tim Caswell <t...@creationix.com> wrote:
>
> Cool.  Just be aware that __proto__ is both non standard and deprecated.
> I'm not sure how this would be done with pure ES5 or ES6 code though.  I
> really like how protein just returns a function and doesn't mess with the
> HttpServer or subclass it like connect does.
>
> On Thu, Apr 12, 2012 at 2:06 PM, Mathias Buus <mathiasb...@gmail.com>wrote:
>
>> Yes I am mutating the __proto__ link of the request and response.
>>
>> One question, how do you extend the prototypes once (not per request)
>> without changing the http prototypes.  Are you mutating the .__proto__ of
>> the request when it comes in from node?
>>
>>
>>  --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>  --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>  --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to