But yeah there are situations where hooks were not planed. For example:
Once I tried to mock the file system. The goal were to define directory
layout right in test. That's much more better and cleaner then having
separate fixtures dir created by hand. You have all information right were
it used, you have instant understanding of what's going on, etc. But you
can't mock file system if you need real IO right in the test and at the
same time you are using third party! Anyway, even if you don't have such
case, isn't it better to just use "require" for things that semantically
are nothing more then just a "require", rather then introduce artificial
hooks?
On Saturday, July 28, 2012 2:02:05 AM UTC+4, Marak Squires wrote:
> Yeah, that's pretty much the whole point of Broadway.
> I use Broadway a lot of "plugin systems". Essentially, where you are
> requiring files as node.js modules, but you want programmatic hooks into
> the initialization and attachment process of the module.
> On Fri, Jul 27, 2012 at 2:57 PM, Joshua Holbrook <josh.holbr...@gmail.com>wrote:
>> You might like this, Eldar:
>> https://github.com/flatiron/broadway
>> It gives you dependency injection and IoC. We use it a lot in
>> flatiron, it's pretty sweet.
>> --Josh
>> On Fri, Jul 27, 2012 at 2:27 PM, Rob Ashton
>> <robashtondevelo...@gmail.com> wrote:
>> > Yeah, sorry
>> > Not a real developer, never worked on a real project, excuse me for my
>> > ignorance.
>> > Lol jking
>> > Sigh
>> > Sent from my iPhone
>> > On 27 Jul 2012, at 20:33, Joe Developer <joe.d.develo...@gmail.com>
>> wrote:
>> > Erm, outside of the amateur hour projects just such functionality
>> exists:
>> > http://blog.endpoint.com/2011/02/locally-served-yui3.html
>> > And yes, once you have had the pleasure of using it on non-trivial apps
>> you
>> > miss it dearly when dealing with the ad-hoc structured or 'good enough
>> > rolled' alternatives.
>> > On Fri, Jul 27, 2012 at 11:47 PM, Martin Cooper <mfncoo...@gmail.com>
>> wrote:
>> >> On Fri, Jul 27, 2012 at 8:07 AM, Rob Ashton <robash...@codeofrob.com>
>> >> wrote:
>> >> > Do we need dependency injection in nodejs? Well - if you mean
>> dependency
>> >> > injection literally, we have it already, it looks like this
>> >> > function doSomething(dependency) {
>> >> > }
>> >> > doSomething(new FooDependency())
>> >> > or
>> >> > doSomething(new BarDependency())
>> >> > or
>> >> > var Animal = function(vocals) {
>> >> > this.vocals = vocals
>> >> > }
>> >> > var cat = new Animal(miaow)
>> >> > cat dog = new Animal(woof)
>> >> > etc
>> >> > ----------
>> >> > If you're talking about 'container' support to support this, it's a
>> >> > road
>> >> > that has been trodden well by .NET and Java devs, and has been shown
>> >> > time
>> >> > and time again to lead full circle to the very beginning where you
>> just
>> >> > build your object graphs manually and introduce extensibility points
>> >> > where
>> >> > you need them for either mocking out slow dependencies for testing or
>> >> > allowing consumers to control something about your code.
>> >> > Trying to bake in support to this as part of the require system seems
>> >> > like
>> >> > asking for trouble, keep it explicit, keep it as needed and let the
>> >> > goodness
>> >> > follow.
>> >> I agree with this. If you need dependency injection, design it into
>> >> your system. Don't force it on unsuspecting modules.
>> >> A couple of things that come to mind off the top of my head:
>> >> * If I compel some module to use, say, 'my-funky-fs' instead of 'fs'
>> >> without knowing it, will that cause *its* dependencies to have their
>> >> usage of 'fs' replaced too? What if one of them was already replacing
>> >> it with something of its own choosing, perhaps using a different
>> >> mechanism (like maybe graceful-fs)?
>> >> * If someone reports an issue with one of my packages, and I spend a
>> >> bunch of my time debugging it, only to discover that the reporter
>> >> replaced one of my dependencies with some other flaky substitute and
>> >> that's the culprit, I'm not going to be happy about that. I design my
>> >> packages to work with their declared dependencies, or I specifically
>> >> design for dependency injection if it's needed.
>> >> > My two cents.
>> >> And mine. :)
>> >> --
>> >> Martin Cooper
>> >> > On Fri, Jul 27, 2012 at 4:45 PM, Eldar <eldar...@gmail.com> wrote:
>> >> >> Do we need this in Node?
>> >> >> My answer is yes we need some (simple) way to specify the app level
>> >> >> dependencies at runtime. Here is my take on this. Please checkout
>> and
>> >> >> let
>> >> >> me know how do you feel about.
>> >> >> But the idea is very simple:
>> >> >> // inside any index.js
>> >> >> var R = require('runtime').patchNative()
>> >> >> var use = R(module).use
>> >> >> use('fs', 'node_modules/third/party', require('./smart-fs'))
>> >> >> That's it. Third party module just uses our smart file system
>> >> >> --
>> >> >> 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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/nodejs?hl=en?hl=en
>> --
>> Joshua Holbrook
>> Head of Support
>> Nodejitsu Inc.
>> j...@nodejitsu.com
>> --
>> 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+unsubscribe@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
> --
