[ANN] Needle 1.0.0

[Jamis Buck]

Needle is a dependency injection (a.k.a. "inversion of control")
container for Ruby, employing many of Ruby's best idioms to make
dependency injection and service location fast, friendly, and fun! It
has never been easier to take advantage of these powerful design
patterns. Treat yourself and download it today!

Project page: http://rubyforge.org/projects/needle
Users Manual: http://needle.rubyforge.org
FAQ document: http://needle.rubyforge.org/faq.html
API document: http://needle.rubyforge.org/api
Needle Wiki: http://needle.rubyforge.org/wiki/wiki.pl

Mailing list: http://rubyforge.org/mailman/listinfo/needle-discuss
Disussion Forums: http://rubyforge.org/forum/?group_id=410
Bug tracker: http://rubyforge.org/tracker/?atid=1642&group_id=410
Feature Req: http://rubyforge.org/tracker/?atid=1645&group_id=410

Version 1.0.0 provides a complete FAQ document and Users Guide (although
I'm sure there are still omissions, over-simplifications, and out-right
lies scattered all through both documents).

This release also adds Container#require (to support service libraries)
and fixes various bugs and typos.

As of this release, the API is considered "stable". No
backwards-incompatible changes will be made to the API during the 1.x
series of releases.

USAGE:

require 'needle'

reg = Needle::Registry.define do |b|
b.foo { Foo.new }
b.bar { Bar.new( b.foo ) }
...
end

bar = reg.bar

See the Users Manual and the 'examples' subdirectory of the Needle
distribution for more usage examples.

 

[George Moschovitis]

Needle is a dependency injection (a.k.a. "inversion of control")
... distribution for more usage examples.

Congratulations and thank you very much

-g.

 

[Jason Voegele]

Jamis Buck said:

Needle is a dependency injection (a.k.a. "inversion of control")
container for Ruby, employing many of Ruby's best idioms to make
dependency injection and service location fast, friendly, and fun! It
has never been easier to take advantage of these powerful design
patterns. Treat yourself and download it today!

What is the relationship (if any) between Copland and Needle? Is Needle
the successor to Copland?

--
Jason Voegele
"There is an essential core at the center of each man and woman that
remains unaltered no matter how life's externals may be transformed
or recombined. But it's smaller than we think."
-- Gene Wolfe, The Book of the Long Sun

 

[Jamis Buck]

Jamis Buck said:



What is the relationship (if any) between Copland and Needle? Is Needle
the successor to Copland?

Copland and Needle are two independent projects. They are unrelated
(although Needle does borrow some code from Copland, such as the logging
subsystem).

Copland, though functional, is pretty overengineered from a Ruby
standpoint. I used a lot of Java-isms to implement it, and although Java
requires that kind of complexity to accomplish dependency injection,
Ruby does not.

Compare LOC:

Copland 1.0: 5,962
Needle 1.1: 2,455

(Needle 1.1 will be out later this week--that's not a typo.)

Needle is less than half the mass of Copland, and yet it has the same
core functionality: interceptors, logging subsystem, dependency
injection, etc. However, whereas Copland uses external configuration
files, Needle uses Ruby as a domain language to register services.

Needle is significantly faster to start up than Copland. For example,
the calculator demo (on my laptop) takes 0.096s to start up for Copland,
but only 0.026 seconds for Needle. For a standalone app, that might not
matter, but in a CGI environment where the registry will be created for
every request, the registry load times for Copland could become prohibitive.

Copland is designed with "fail-fast" in mind. That is to say, if you
misconfigure your services, Copland tries to detect and error out as
soon as possible. Needle makes very little effort to do the same.

Needle has a much more flexible model for service lifecycle management
than Copland, but only because I didn't think of it until I was writing
Needle. Needle's pipeline model could (theoretically) be ported back to
Copland, but I do not have any plans to do so.

Also, although theoritically Copland can do anything that Needle can,
you may need to write a lot of code for Copland in some cases to
accomplish something Needle can do "out-of-the-box", since Needle uses
Ruby as its configuration language.

Lastly, Needle does sport one feature that Copland does not:
hierarchical namespaces. Copland pretends to have these, but in reality
all packages in Copland are laid out flat, as siblings of each other.
Needle actually allows you to nest namespaces, with services in a
namespace overriding the services in its parent namespaces. This gives
you a lot of power that Copland cannot provide.

So, you should use Copland if:

* you prefer external configuration over configuration in Ruby
* you want "fail-fast" functionality
* you are primarily a Java developer and prefer to think that way
* lengthy registry load times are not a factor

You should use Needle if:

* you prefer to use Ruby's idioms (blocks, etc.) to configure services
* you don't need "fail-fast" functionality
* short load times are important
* you need maximum flexibility in defining services
* you need hierarchical namespaces with overridable services

Anyway, that was a longer explanation than I had intended to write.
There are other differences (I'm thinking of more even as I write this
conclusion, like Needle's lack of eager loading and shutdown
notification), but the above should give you an idea of how the two
differ. Hope it helps.

- Jamis

 

[Nikolai Weibull]

Copland, though functional, is pretty overengineered from a Ruby
standpoint. I used a lot of Java-isms to implement it, and although Java
requires that kind of complexity to accomplish dependency injection,
Ruby does not.

Yeah. When I saw Copland, I thought that it seemed a bit much to do
something as "simple" as that, but when Needle was announced I really
thought that it could be useful. The simplicity of using Needle really
appeals to me.
nikolai

 

[James Britt]

Jamis Buck wrote:

...

Anyway, that was a longer explanation than I had intended to write.
There are other differences (I'm thinking of more even as I write this
conclusion, like Needle's lack of eager loading and shutdown
notification), but the above should give you an idea of how the two
differ. Hope it helps.

Are both under active development?


Thanks,

James

 

[Jamis Buck]

Jamis Buck wrote:

...



Are both under active development?

Please, I'm only one man, James!

I'm actively developing Needle right now (more actively than I'd
intended...I'd hoped to release 1.0 and then focus on other things, but
some worthwhile enhancements were suggested to me, and I thought of a
few things I'd like to add...so 1.1 is coming out later this week).

For now, Copland development (though not support) is dormant. I'm still
debating whether Copland has value or not--if anyone is has tried both
Copland and Needle and has a preference for Copland, I'd love to hear
from you regarding your reasons. Otherwise, the odds of future
development being done on Copland (by me) are rather slim.

I've toyed with the idea of reimplementing Copland (again), building it
on top of Needle. I still see some value in external configuration (as
opposed to doing in in Ruby), and I also like Copland's emphasis on
fail-fast. That said...another reimplementation doesn't really appeal to
me at this point, so it would probably some time down the road before I
find the motivation to work on that.

- Jamis

 

[James Britt]

Please, I'm only one man, James!

But legend has it you have the strength of 10 men.


James

 

[Jason Voegele]

Jamis Buck said:

I've toyed with the idea of reimplementing Copland (again), building it
on top of Needle. I still see some value in external configuration (as
opposed to doing in in Ruby), and I also like Copland's emphasis on
fail-fast. That said...another reimplementation doesn't really appeal to
me at this point, so it would probably some time down the road before I
find the motivation to work on that.

Thanks for the explanation re: Needle and Copland in your previous mail.

Regarding allowing the option of external configuration, I'd be very much
in favor of providing that as an option. Spring, a DI framework for Java
(as I'm sure you know) allows for choosing between XML files, properties
files, or Java code for configuring service objects. I like this
flexibility. I think that external configuration is especially important
if end users may be the ones doing the configuration.

Thanks again. I'm looking forward to trying out Needle and perhaps
Copland as well.

--
Jason Voegele
"There is an essential core at the center of each man and woman that
remains unaltered no matter how life's externals may be transformed
or recombined. But it's smaller than we think."
-- Gene Wolfe, The Book of the Long Sun

 

[Nikolai Weibull]

Regarding allowing the option of external configuration, I'd be very
much in favor of providing that as an option. Spring, a DI framework
for Java (as I'm sure you know) allows for choosing between XML files,
properties files, or Java code for configuring service objects. I
like this flexibility. I think that external configuration is
especially important if end users may be the ones doing the
configuration.

Exactly why should a user be forced to mess around with configuration
files written in, for example, yaml? I'm not against textual
configuration, I just don't think it's the users place to mess around
with files vital to the proper execution of an application to use it;
even if this is a feature mostly expolited by "expert users".
Configuration of this kind is best abstracted another level in my
opinion.
nikolai