needle 0.5.0 → 0.6.0

data/benchmarks/instantiability.rb

@@ -0,0 +1,26 @@
+$:.unshift "../lib"
+
+require 'benchmark'
+require 'needle'
+
+ITERATIONS = 100_000
+
+registry = Needle::Registry.new
+registry.register( :deferred, :model=>:singleton_deferred ) { Struct.new( :value ).new( 1 ) }
+registry.register( :immediate, :model=>:singleton ) { Struct.new( :value ).new( 1 ) }
+
+deferred = registry.deferred
+immediate = registry.immediate
+
+puts
+puts "--------------------------------------------------------------------"
+puts "Proxied method dispatch vs. direct method dispatch"
+puts "#{ITERATIONS} iterations"
+puts
+
+Benchmark.bm(7) do |x|
+  x.report( "proxy:" ) { ITERATIONS.times { deferred.value } }
+  x.report( "direct:" ) { ITERATIONS.times { immediate.value } }
+end
+
+puts

data/benchmarks/instantiation.rb

@@ -0,0 +1,33 @@
+$:.unshift "../lib"
+
+require 'benchmark'
+require 'needle'
+
+ITERATIONS = 100_000
+
+S = Struct.new( :value )
+
+registry = Needle::Registry.new
+registry.register( :immediate, :model=>:prototype ) { S.new }
+registry.register( :deferred, :model=>:prototype_deferred ) { S.new }
+
+puts
+puts "--------------------------------------------------------------------"
+puts "Direct vs. Immediate vs. Deferred instantiation (trivial)"
+puts "#{ITERATIONS} iterations"
+puts
+
+Benchmark.bm(10) do |x|
+  GC.disable
+  x.report( "direct:" ) { ITERATIONS.times { S.new } }
+  GC.start
+  x.report( "immediate:" ) { ITERATIONS.times { registry.immediate } }
+  GC.start
+  x.report( "deferred:" ) { ITERATIONS.times { registry.deferred } }
+  GC.start
+  x.report( "deferred*:" ) { ITERATIONS.times { registry.deferred.value } }
+  GC.enable
+end
+
+puts "* this benchmark forced the proxy to instantiate its wrapped service"
+puts

data/benchmarks/interceptors.rb

@@ -0,0 +1,42 @@
+$:.unshift "../lib"
+
+require 'benchmark'
+require 'needle'
+
+ITERATIONS = 100_000
+
+class TrivialInterceptor
+  def initialize( point, parms )
+  end
+
+  def process( chain, ctx )
+    chain.process_next( ctx )
+  end
+end
+
+registry = Needle::Registry.new
+registry.register( :interceptor ) { TrivialInterceptor }
+registry.register( :direct ) { Struct.new( :value ).new }
+registry.register( :intercepted_doing ) { Struct.new( :value ).new }
+registry.register( :intercepted_with ) { Struct.new( :value ).new }
+
+registry.intercept( :intercepted_doing ).doing { |chain,ctx| chain.process_next(ctx) }
+registry.intercept( :intercepted_with ).with { registry.interceptor }
+
+direct = registry.direct
+intercepted_doing = registry.intercepted_doing
+intercepted_with = registry.intercepted_with
+
+puts
+puts "--------------------------------------------------------------------"
+puts "Direct method dispatch vs. intercepted method dispatch (trivial)"
+puts "#{ITERATIONS} iterations"
+puts
+
+Benchmark.bm(20) do |x|
+  x.report( "direct:" ) { ITERATIONS.times { direct.value } }
+  x.report( "intercepted (doing):" ) { ITERATIONS.times { intercepted_doing.value } }
+  x.report( "intercepted (with):" ) { ITERATIONS.times { intercepted_with.value } }
+end
+
+puts

data/benchmarks/interceptors2.rb

@@ -0,0 +1,70 @@
+$:.unshift "../lib"
+
+require 'benchmark'
+require 'needle'
+
+ITERATIONS = 10_000
+
+class UnloggedBeast
+  def value( p1, p2 )
+    [ p1, p2 ]
+  end
+end
+
+class LoggedBeast < UnloggedBeast
+  attr_writer :log
+
+  def value( p1, p2 )
+    @log.debug( "value(#{p1.inspect}, #{p2.inspect})" ) if @log.debug?
+    result = super
+    @log.debug( "value(...) => #{result.inspect}" ) if @log.debug?
+    return result
+  rescue Exception => e
+    @log.debug( "value(...) raised #{e.message.inspect} (#{e.class})" ) if @log.debug?
+    raise
+  end
+end
+
+registry = Needle::Registry.new( :logs=> { :filename=>"/dev/null" } )
+registry.register( :direct ) do
+  beast = LoggedBeast.new
+  beast.log = registry.logs.get( "direct" )
+  beast
+end
+
+registry.register( :intercepted_doing ) { UnloggedBeast.new }
+registry.register( :intercepted_with ) { UnloggedBeast.new }
+
+registry.intercept( :intercepted_doing ).
+  with_options( :log => registry.logs.get( "doing" ) ).
+  doing do |chain,ctx|
+    log = ctx.data[:options][:log]
+    begin
+      log.debug( "#{ctx.sym}(#{ctx.args.map{|i|i.inspect}.join(",")})" ) if log.debug?
+      result = chain.process_next(ctx)
+      log.debug( "#{ctx.sym}(...) => #{result.inspect}" ) if log.debug?
+      result
+    rescue Exception 
+      log.debug( "value(...) raised #{e.message.inspect} (#{e.class})" ) if log.debug?
+    end
+  end
+
+registry.intercept( :intercepted_with ).with { registry.logging_interceptor }
+
+direct = registry.direct
+intercepted_doing = registry.intercepted_doing
+intercepted_with = registry.intercepted_with
+
+puts
+puts "--------------------------------------------------------------------"
+puts "Direct method dispatch vs. intercepted method dispatch (non-trivial)"
+puts "#{ITERATIONS} iterations"
+puts
+
+Benchmark.bm(20) do |x|
+  x.report( "direct:" ) { ITERATIONS.times { direct.value( :a, :b ) } }
+  x.report( "intercepted (doing):" ) { ITERATIONS.times { intercepted_doing.value( :a, :b ) } }
+  x.report( "intercepted (with):" ) { ITERATIONS.times { intercepted_with.value( :a, :b ) } }
+end
+
+puts

data/doc/README

@@ -12,6 +12,8 @@ closures and +instance_eval+.
 * API Documentation: http://needle.rubyforge.org/api
 * Needle Wiki: http://needle.rubyforge.org/wiki/wiki.pl
 
+For an excellent overview of dependency injection, have a look at "Dependency Injection in Ruby" (link:files/doc/di-in-ruby_rdoc.html).
+
 == Downloading
 
 You may download Needle from Needle's RubyForge project, at http://rubyforge.org/projects/needle.
@@ -61,7 +63,7 @@ Thanks go to:
 
 == License
 
-Needle is copyright (c) 2004 Jamis Buck.  It is free software, and may be redistributed
+Needle is copyright (c) 2004 Jamis Buck.  It is open-source software, and may be redistributed
 under the terms of the BSD or Ruby licenses. The texts of these licences are included in the
 Needle distribution, under the +doc+ subdirectory.
 

data/doc/di-in-ruby.rdoc

@@ -0,0 +1,201 @@
+= Dependency Injection in Ruby
+By Jim Weirich, slightly adapted for Needle (original article at http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc)
+
+<em>(The API described in the original version of this article inspired the creation of the Needle framework. This article has been modified slightly so that the DI examples use Needle, instead of the framework Jim originally presented. This has proven to be a very minor modification, since the two syntaxes are nearly identical. -- Jamis Buck (jgb3@email.byu.edu))</em>
+
+<em>This article is modified and distributed under the terms of the Creative Commons Attribution-NonCommercial 1.0 license (http://creativecommons.org/licenses/by-nc/1.0).</em>
+
+== What is Dependency Injection?
+
+Consider the problem of putting together a moderately complex OO program. Typical OO programs create a bunch of objects, wire them together in interesting ways and then let the objects run. It is the first two steps, creating and wiring, that are addressed by Dependency Injection (DI).
+
+By the way, another term for dependency injection is Inversion of Control (IOC). Unfortunately, so many things in computer science are called inversion of control that the phrase does not evoke the right connotations with me, so I tend to avoid it. But Inversion of Control is the older term for this pattern so you will see it in many places.
+
+== A Moderately Complex Example
+
+One of the problems with explaining Dependency Injection is that DI only becomes really useful in larger projects. Using a simple example to explain DI leaves the listener thinking "But I can do that easily by (<em>fill in the blank</em>)". So my example is going to be a bit more complex, but hopefully not so large that the reader is unable to understand it.
+
+Imagine you have a webapp that tracks the prices of stocks over time. The application is nicely partitioned into different modules that each handle a portion of the job. A +StockQuotes+ module talks to a remote web service to pull down the current values of the stocks you are tracking. A +Database+ module records the stock values over time. Because this data is highly competitive, you require a login to use the system and thus have an +Authentication+ module to handle validation of user names and password. In addition to these "main" modules, there are a number of additional utility modules used by multiple modules: +ErrorHandler+ to standardize the handling and reporting of error messages and +Logger+ to provide a standard way of logging messsages.
+
+A fully wired system might look something like this:
+
+link:files/doc/images/di_classdiagram.jpg
+
+== Building it Old Style!
+
+In the bad, old days, we would just put the logic of building the web app directly into its initialize method. It might look something like this...
+
+  class WebApp
+    def initialize
+      @quotes = StockQuotes.new
+      @authenticator = Authenticator.new
+      @database = Database.new
+      @logger = Logger.new
+      @error_handler = ErrorHandler.new
+    end
+    # ...
+  end
+
+That handles building the WebApp well enough, but what about the subordinate modules. How does the +StockQuotes+ module find out about the logger and error handler, or how does the +Authenticator+ find the database and logger?
+
+We could rewrite <tt>WebApp#initialize</tt> to create everything in the right order and then pass the logger and error handler to +StockQuotes+. But that makes the web app rather dependent on details of the +StockQuotes+ module. Currently the database module is created after the quote module, but suppose a change in +StockQuotes+ causes it to need the database. That would require the WebApp to be aware of the change, rearrange the order of creation so that the database is created before the stock quotes module and finally make the database available to the quote service. Yuck!
+
+Even worse, the WebApp knows the _concrete_ name of every module it uses. If I wanted to create an instance of the WebApp for testing, I might want to provide a mock quote service so that I can control the quotes used in testing. Or I might want a mock database for testing. All of these choices are difficult because WebApp knows the class name of all its subordinates.
+
+== Enter the Service Locator
+
+We would like to remove the explicit reference to class names in WebApp, but still allow it to locate the services it needs. The <em>Service Locator</em> pattern was designed to address this problem.
+
+With Service Locator, we place references to services in one container and then pass that container to the modules that need to locate those services.
+
+  def create_application
+    locator = {}
+    locator[:logger] = Logger.new
+    locator[:error_handler] = ErrorHandler.new(locator)
+    locator[:quotes] = StockQuotes.new(locator)
+    locator[:database] = Database.new(locator)
+    locator[:authenticator] = Authenticator.new(locator)
+    locator[:webapp] = WebApp.new(locator)
+  end
+
+The initialize function for a service just uses the locator to find the services. Here is how +StockQuotes+ might look...
+
+  class StockQuotes
+    def initialize(locator)
+      @error_handler = locator[:error_handler]
+      @logger = locator[:logger]
+    end
+    # ...
+  end
+
+Not bad. Now no service is aware of the exact class used for the other services. We can reconfigure the system easily by editted the +create_application+ method.
+
+We use the Service Locator pattern (and variations) at work in our Java system.
+
+== External Configuration
+
+Although we built the service locator in Ruby code, it would not be difficult to specify the locator as a configuration file. A simple Ruby method could read the file, instantiate the objects and populate a hash table. This might allow non-programmers to tweak a configuration to their liking.
+
+== More Goodness
+
+Another neat thing about the locator is that we can use it to configure data as well as modules. Suppose we wanted to specify the file to be used as the log file. We might modify the +create_application+ method to include the following:
+
+  locator[:log_file_name] = "webapp.log"
+  locator[:logger] = Logger.new(locator)
+
+And +Logger+ would have to know that the log file was identified by <tt>:log_file_name</tt> in the locator. The +Database+ module is another likely candidate for locator based information (e.g. DB user name and password, DB host name).
+
+== But ...
+
+As good as the Service Locator pattern is, there are still some negatives. Every class that uses the locator needs to be written expecting a locator as an argument to +initialize+ method. This is not a natural idiom for Ruby programmer. In the absence of Service Locators, I would expect that the +Logger+ class would be written like this ...
+
+  class Logger
+    def initialize(log_filename)
+      # ...
+    end
+    # ...
+  end
+
+which would make it unusable in a system that depended upon service locators.
+
+Another downside is that all modules that use the locator must agree on the names of the services. For example, if MyLogger expects its file name to be under <tt>:log_filename</tt> and +YourLogger+ expects to find its filename under <tt>:log_file</tt> then the two loggers are not plug replaceable.
+
+Also, suppose both +StackQuotes+ and +Database+ found their loggers using <tt>:logger</tt>, but we want to give them separate logger instances for some reason. The explicit dependence on the name of the logger service makes this a bit difficult.
+
+And finally, the service locator did not solve the problem of creation order. The database is still created after the stock quotes module, causing problems if the stocks quotes module were modified to use the database.
+
+None of the problems are show stoppers and there are workarounds for each, but it does make us wonder if there is a more general solution.
+
+== Finally, Dependency Injection
+
+Dependency Injection is much like using service locators in that we identify the services by name. The big difference is that dependency injectors also take the responsibility of creating the service objects and making sure the dependent services are provided as needed.
+
+This means that the services can be written in complete ignorance of dependency injection framework. All they need to do is make sure that they can be told about the services they need, either through parameters to a constructor, or through some kind of setter.
+
+It also means that dependency injectors are a bit more complicated than service locators, since they also handle the creation of the services as well.
+
+== Dependency Injection in Action
+
+How does dependency injection work? Generally, you create a DI container that is configured to know how to create the various services. Then you just ask for a service by name, and the container will create the serice (if needed) and give it to you.
+
+For example, configuring a logger service is as easy as ...
+
+   registry = Needle::Registry.new
+   registry.register(:logger) { Logger.new )
+
+This says that the logger service is named <tt>:logger</tt>. The first time a logger service is requested, the block supplied to register will be called and a logger object will be created. Subsequent requests for a logger will return the already created logger.
+
+To get a logger service, all you need to do is ask:
+
+   logger = registry.logger
+
+*Note*:: In my examples, Service Locators were hash based, so using [] to access the services seems like a natural choice. For dependency injection containers, I chose to use a message-like syntax to access services (e.g. registry.logger). Either notation can be used for either service locators or dependency injection containers. In fact, the Needle dependency injection framework supports both selecter messages and hash-like indexing (registry[:logger]).
+
+If a logger requires a parameter, then you can easily handle that in the registration block.
+
+  registry.register(:logger) { Logger.new("logfile.log") }
+
+If you would rather have the logger get its log filename from the container, you can do this ...
+
+  registry.register(:logger) { |c| Logger.new(c.log_filename) }
+
+And then somewhere else you can specify the log name ...
+
+  registry.register(:log_filename) { "logfile.log" }
+
+== Configuring the WebApp with Dependency Injection
+
+Now that we've seen some DI in action, let's try it on our web app ...
+
+  def create_application
+    registry = Needle::Registry.new
+    registry.register(:logfilename) { "logfile.log" }
+    registry.register(:db_user) { "jim" }
+    registry.register(:db_password) { "secret" }
+    registry.register(:dbi_string) { "DBI:Pg:example_data" }
+
+    registry.register(:app) do |c|
+      app = WebApp.new(c.quotes, c.authenticator, c.database)
+      app.logger = c.logger
+      app.set_error_handler c.error_handler
+      app
+    end
+
+    registry.register(:quotes) { |c|
+      StockQuotes.new(c.error_handler, c.logger)
+    }
+
+    registry.register(:authenticator) { |c|
+      Authenticator.new(c.database, c.logger, c.error_handler)
+    }
+
+    registry.register(:database) { |c|
+      DBI.connect(c.dbi_string, c.db_user, c.db_password)
+    }
+
+    registry.register(:logger) { |c| Logger.new(c.logfilename) }
+    registry.register(:error_handler) do |c|
+      errh = ErrorHandler.new
+      errh.logger = c.logger
+      errh
+    end
+
+    registry.app
+  end
+
+As you can see, it is a bit more complicated than the service locator. The main reason for the complexity is that we have moved the creation logic out of the services and into the DI container. What we have gained is the ability to inject dependencies into any object without having to make special code changes to support it.
+
+Just a few closing notes:
+
+* Both constructor injection (+StockQuotes+) and setter injection (+ErrorHandler+) or a combination of both (+WebApp+) can be supported with this framework.
+* We can even handle cases where the creation method is not named "+new+" (DBI).
+* If a poorly written service didn't provide a way to inject the services it depends upon, we _could_ use +instance_variable_set+ to force a dependent service into place. Obviously, this would be less than desireable.
+* The order of the registration doesn't matter, since no service is created until everything is registered. If the +StockQuotes+ module suddenly starts needing a database connection, no problem. We just add a reference to a database service in the creation code for +StockQuotes+ and we are done. The DI framework worries about making sure the database is _created_ before anything that needs it.
+* The container doesn't have to be configured in one place. For example, we could move the first four register calls to a separate file that would allow the log file and database information to be modified independently of the rest.
+* There still needs to be agreement about service names, but now only the container knows about them. The individual services don't care.
+* Since the DI container is responsible for all the service names and service creation, it is easy to intercept a service and wrap an AOP-like wrapper around a it.
+* Just like the service locator, a DI container could be configured through a configuration file. The configuration would be more complex (because the DI container is more complex), but still quite doable. Another idea is to use Ruby as Domain Specific Language for DI container configuration.
+
+== Summary
+
+Both the Service Locator and Dependency Injection patterns are quite useful, but each has different tradeoffs between flexibility and complexity. Understand the differences and you will have all you need to choose the proper idiom for any given circumstance.

data/doc/manual/manual.yml

@@ -22,12 +22,16 @@ product: !^product
     - Needle Wiki: http://needle.rubyforge.org/wiki/wiki.pl
 
 recent_updates:
+- added Container#define
+- renamed Container#register! to Container#define!
+- added documentation of Container#new!
 
 chapters:
 
 - Introduction:
   - What is Needle?: !!file parts/01_what_is_needle.txt
   - How Can It Help Me?: !!file parts/01_use_cases.txt
+  - Alternatives: !!file parts/01_alternatives.txt
   - License Information: !!file parts/01_license.txt
   - Support: !!file parts/01_support.txt
       

data/doc/manual/parts/01_alternatives.txt

@@ -0,0 +1,11 @@
+Needle is not the only fish in the dependency-injection pond, even when it comes to Ruby. Other containers at your disposal include:
+
+* "Copland":http://copland.rubyforge.org. Copland aims to be an "application framework", taking something of a heavy-weight approach to DI. In so doing, it provides functionality that Needle does not, but at the cost of performance. It also uses external (YAML) configuration files. It is inspired by a Java framework ("HiveMind":http://jakarta.apache.org/hivemind), and so has a vaguely Java-ish flavor to it.
+* "Rico":http://www.picocontainer.org/Rico. Rico is another project inspired by a Java project ("PicoContainer":http://www.picocontainer.org). It is very lean, and appears to be experimental.
+* "Tudura":http://sourceforge.jp/projects/nihohi/. I do not have any information on this project, as the information is all in Japanese. If someone with more information about Tudura would like to step forward, I'd be happy to post a summary here.
+
+There is, at the time of this writing, at least one other project on RubyForge devoted to DI, although it has no public releases yet.
+
+So, which one should you choose? It comes down to an issue of personal preference, mostly, but also one of what you are wanting to accomplish. Needle excels at providing an unobtrusive, light-weight container for managing your dependencies. The cost of it being light-weight is that there is functionality it does not provide, which other containers may. If you really need that missing functionality, you are required to either implement it yourself, or select a different container.
+
+For most tasks, I think you'll find Needle more than sufficient.

data/doc/manual/parts/02_creating.txt

@@ -7,3 +7,23 @@ Creating a registry is as simple as calling @Needle::Registry.new@. This will gi
 </pre>
 
 Once you have the reference to the registry, you can register services with it, create new namespaces in it, and so forth.
+
+Alternatively, you can pass a block to @#new@:
+
+<pre>
+  registry = Needle::Registry.new do |r|
+    ...
+  end
+</pre>
+
+The parameter to the block will be a reference to the registry. This allows you to register services with the registry as soon as it is created.
+
+One other convenience method is @#new!@:
+
+<pre>
+  registry = Needle::Registry.new! do
+    ...
+  end
+</pre>
+
+This block accepts no parameters, and evaluates the block as if it were passed to @Registry#define!@ (see below).

data/doc/manual/parts/02_namespaces.txt

@@ -35,7 +35,7 @@ Because it is often the case that you will be creating a namespace and then imme
   end
 </pre>
 
-And, to mirror the @register!@ method, there is also a @namespace!@ method. This method creates a new namespace and then does a @register!@ call on that namespace.
+And, to mirror the @namespace@ method, there is also a @namespace!@ method. This method creates a new namespace and then does a @define!@ call on that namespace.
 
 <pre>
   registry.namespace! :stuff do

data/doc/manual/parts/02_services.txt

@@ -18,17 +18,29 @@ You get services from the registry in either of two ways:
 
 h3. Convenience Methods
 
-Because you will often need to register many services with a registry at once, a convenience method has been provided to make this use case lean and mean. Just call @registry!@, passing a block that accepts no parameters. This block will be evaluated in a new context, with any unrecognized method call being interpreted as a new service registration of that name:
+Because you will often need to register many services with a registry at once, two convenience methods have been provided to make this use case lean and mean.
+
+The first is @define@. Just pass a block to define that accepts one parameter. This parameter will be a "builder" object that allows you to define services just by sending them as messages to the builder:
+
+<pre>
+  registry.define do |b|
+    b.foo { Bar.new }
+    b.bar { Foo.new }
+    ...
+  end
+</pre>
+
+Alternative, you can call @define!@, passing a block that accepts no parameters. This block will be evaluated in the "builder" object's context, with any unrecognized method call being interpreted as a new service registration of that name:
 
 <pre>
-  registry.register! do
+  registry.define! do
     foo { Bar.new }
     bar { Foo.new }
     ...
   end
 </pre>
 
-The above will register two new services with the registry, @:foo@ and @:bar@.
+Both of the above will register two new services with the registry, @:foo@ and @:bar@.
 
 h3. Default Lifecycle
 

data/doc/manual-html/chapter-1.html

@@ -14,8 +14,8 @@
           </div>
         </td><td valign='middle' align='right'>
           <div class="info">
-            Needle Version: <strong>0.5.0</strong><br />
-            Manual Last Updated: <strong>2004-10-15 03:41 GMT</strong>
+            Needle Version: <strong>0.6.0</strong><br />
+            Manual Last Updated: <strong>2004-10-21 16:17 GMT</strong>
           </div>
         </td></tr>
       </table>
@@ -41,9 +41,11 @@
                 
                   <li><a href="chapter-1.html#s2">How Can It Help Me?</a></li>
                 
-                  <li><a href="chapter-1.html#s3">License Information</a></li>
+                  <li><a href="chapter-1.html#s3">Alternatives</a></li>
                 
-                  <li><a href="chapter-1.html#s4">Support</a></li>
+                  <li><a href="chapter-1.html#s4">License Information</a></li>
+                
+                  <li><a href="chapter-1.html#s5">Support</a></li>
                 
               </ol>
             </li>
@@ -315,7 +317,32 @@
 
      <h2>
        <a name="s3"></a>
-       1.3. License Information
+       1.3. Alternatives
+     </h2>
+
+   
+
+   <div class="section">
+     <p>Needle is not the only fish in the dependency-injection pond, even when it comes to Ruby. Other containers at your disposal include:</p>
+
+	<ul>
+	<li><a href="http://copland.rubyforge.org">Copland</a>. Copland aims to be an &#8220;application framework&#8221;, taking something of a heavy-weight approach to DI. In so doing, it provides functionality that Needle does not, but at the cost of performance. It also uses external (YAML) configuration files. It is inspired by a Java framework (<a href="http://jakarta.apache.org/hivemind">HiveMind</a>), and so has a vaguely Java-ish flavor to it.</li>
+		<li><a href="http://www.picocontainer.org/Rico">Rico</a>. Rico is another project inspired by a Java project (<a href="http://www.picocontainer.org">PicoContainer</a>). It is very lean, and appears to be experimental.</li>
+		<li><a href="http://sourceforge.jp/projects/nihohi/">Tudura</a>. I do not have any information on this project, as the information is all in Japanese. If someone with more information about Tudura would like to step forward, I&#8217;d be happy to post a summary here.</li>
+	</ul>
+
+	<p>There is, at the time of this writing, at least one other project on RubyForge devoted to DI, although it has no public releases yet.</p>
+
+	<p>So, which one should you choose? It comes down to an issue of personal preference, mostly, but also one of what you are wanting to accomplish. Needle excels at providing an unobtrusive, light-weight container for managing your dependencies. The cost of it being light-weight is that there is functionality it does not provide, which other containers may. If you really need that missing functionality, you are required to either implement it yourself, or select a different container.</p>
+
+	<p>For most tasks, I think you&#8217;ll find Needle more than sufficient.</p>
+   </div>
+
+
+
+     <h2>
+       <a name="s4"></a>
+       1.4. License Information
      </h2>
 
    
@@ -332,8 +359,8 @@
 
 
      <h2>
-       <a name="s4"></a>
-       1.4. Support
+       <a name="s5"></a>
+       1.5. Support
      </h2>