DCI 0.1.0 has been released.
Faithful DCI framework for Ruby application development.
* home: https://rubyworks.github.com/dci
* code: https://github.com/rubyworks/dci
* mail: http://groups.google.com/groups/rubyworks-mailinglist
This is the initial working version of DCI.
Changes:
* Happy Birthday!
Make that:
* home: http://rubyworks.github.com/dci <https://rubyworks.github.com/dci>
Hi there,
I have a question... what problems does dependency injection solve that
duck typing does not?
As Rubyists we can compose in such a way that we expect objects which quack
a certain protocol. The method protocol in use becomes a kind of
abstraction, allowing us to swap in other types of objects which quack the
same, but may be completely different objects of a completely different
class with a completely different implementation.
Dependency injection seems like myriad complexity in order to solve a
problem that Ruby already solves by the very nature of its type system. I
have used this sort of approach to simply compose the kinds of systems I
can't fathom being able to build in statically typed languages.
So all that said, what does dependency injection offer Rubyists that duck
typing does not?
On Tue, Feb 7, 2012 at 8:02 AM, <transfire@gmail.com> wrote:
DCI 0.1.0 has been released.
Faithful DCI framework for Ruby application development.
* home: https://rubyworks.github.com/dci
* code: GitHub - rubyworks/dci: Experiment in DCI for Ruby
* mail: http://groups.google.com/groups/rubyworks-mailinglistThis is the initial working version of DCI.
Changes:
* Happy Birthday!
--
Tony Arcieri
Google is pissing me off with their fancy new "wysiwyg" (NOT) replay field.
Try it again:
* home: http://rubyworks.github.com/dci
Okay, never mind me, I'm just a little drunk and got DCI confused with DI.
My bad 
On Tue, Feb 7, 2012 at 10:19 PM, Tony Arcieri <tony.arcieri@gmail.com>wrote:
Hi there,
I have a question... what problems does dependency injection solve that
duck typing does not?As Rubyists we can compose in such a way that we expect objects which
quack a certain protocol. The method protocol in use becomes a kind of
abstraction, allowing us to swap in other types of objects which quack the
same, but may be completely different objects of a completely different
class with a completely different implementation.Dependency injection seems like myriad complexity in order to solve a
problem that Ruby already solves by the very nature of its type system. I
have used this sort of approach to simply compose the kinds of systems I
can't fathom being able to build in statically typed languages.So all that said, what does dependency injection offer Rubyists that duck
typing does not?On Tue, Feb 7, 2012 at 8:02 AM, <transfire@gmail.com> wrote:
DCI 0.1.0 has been released.
Faithful DCI framework for Ruby application development.
* home: https://rubyworks.github.com/dci
* code: GitHub - rubyworks/dci: Experiment in DCI for Ruby
* mail: http://groups.google.com/groups/rubyworks-mailinglistThis is the initial working version of DCI.
Changes:
* Happy Birthday!
--
Tony Arcieri
--
Tony Arcieri
Actually, in implementing this it struck me that DCI is kind of like DI
taken to then next level of abstraction. So your question isn't really that
out of place --to which I would say, you are right. DI really doesn't fit
Ruby, but DCI does bring something more to the table in the way it makes
you think about and implement you problem set.
Actually, I'm not sure DCI is all that great an idea. That remains to be
seen. My goal here was just to create a fairy solid implementation of the
concept (I'd say I'm 80% of the way there at this point), so that people
could at least give it a try/use it as a reference.