mindi 0.5

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: aca8e938147f48488f4e0f0c39a0cf2b2dc73c6d
+  data.tar.gz: 45deba41f62f63149767a778bdb634b54c0d2a4c
+SHA512:
+  metadata.gz: 90b98a6bface5c02dc56a7c12642f612a6e3ce2ba8ed3210c62e9909012277b0f7cfb05c5469a2900c0c6f6ad886d2d3c915b9285ef695142ee586cedecf605c
+  data.tar.gz: b0500a9adb11e764ea026658222e2b9d502e8947601a6567a69bb1973a85269b42357112f1faf44efe513b65c516be8688e14500d56a69f24d89df5f6bf0ff19

data/COPYING

@@ -0,0 +1,22 @@
+Copyright (c) 2004-2014, Joel VanderWerf, vjoel@users.sourceforge.net
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met: 
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer. 
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution. 
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

data/README.md

@@ -0,0 +1,174 @@
+MinDI
+=====
+
+MinDI is Minimalist Dependency Injection for Ruby. It is inspired by Jamis Buck's Needle (http://needle.rubyforge.org) and Jim Weirich's article on DI in Ruby (http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc).
+
+MinDI is minimalist in that it attempts to map concepts of DI into basic ruby
+constructs, rather than into a layer of specialized constructs. In particular, classes and modules function as containers and registries, and methods and method definitions function as service points and services. There are some inherent advantages and disadvantages to this approach, discussed below.
+
+MinDI builds on this minimal DI container by adding the InjectableContainer concept, which is a kind of DI available only in dynamic languages: through the magic of <tt>method_missing</tt>, a service may invoke other services without having explicit setter or constructor references to those services.
+
+Synopsis
+--------
+
+Using the BasicContainer module for constructor injection:
+
+    require 'mindi'
+
+    class SimpleContainer
+      include MinDI::BasicContainer
+
+      greeting { "Hello, world\n" }
+
+      point_at { |x,y| [x,y] }
+
+      stuff { [greeting, point_at(100,200)] }
+    end
+
+    cont = SimpleContainer.new
+
+    p cont.stuff   # ==> ["Hello, world\n", [100, 200]]
+
+Using the InjectableContainer module for "dynamic" or "fallback" injection, using `method_missing`:
+
+    require 'mindi'
+
+    class Transformer
+      def transform string
+        string.gsub(pattern, &replacement)
+      end
+    end
+
+    class TransformerContainer
+      include MinDI::InjectableContainer
+
+      pattern     { /foo/ }
+      replacement { proc {|match| match.upcase } }
+      transformer { Transformer.new }
+      transform   { |str| transformer.transform(str) }
+    end
+
+    cont = TransformerContainer.new
+    s1 = cont.transform("fo foo fee")
+    s2 = cont.transform("fo foo fee")
+    p s1              # ==> "fo FOO fee"
+    p s1.equal?(s2)   # ==> true
+
+
+Note that the Transformer class is written without explicitly linking up
+to services (either in initialize or in setters). It just assumes that
+the services will be defined in the container.
+
+Note also that the #transform service is a multiton service, and (like
+singleton services) it caches its value for each argument.
+
+
+Advantages
+----------
+
+- Compact implementation (the essentials are about 100 lines).
+
+- Compact syntax.
+
+- Familiar constructs and idioms, like subclassing, module inclusion, nested
+  classes, protected and private, all apply.
+
+- Use of classes and methods as containers and services means you can apply a
+  standard AOP or debugging lib.
+
+- Services can take arguments, and this permits multiton services. Like singleton services, multiton services cache their results.
+
+- Dynamic service registration is easy, since ruby's class system is itself
+  so dynamic. See examples/dynamic.rb.
+
+Disadvantages
+-------------
+
+- A container's services live in the same namespace as the methods inherited
+  from Kernel and Object, so a service called "dup", for example, will
+  prevent calling Object#dup on the container (except in the implementation
+  of the dup service, which can use super to invoke Object#dup). The MinDI
+  framework itself adds a few methods that could conflict with services
+  (#singleton, #generic, etc.). Also, the "shortcut" service definition
+  (using method_missing) will not let you define services like "dup"--you
+  would have to use an explicit definer, like #singleton.
+
+- No built-in AOP, logging, debugging, or reflection interface, as in Needle.
+
+Notes
+-----
+
+- Supports threaded, deferred, singleton, and multiton service models (though
+  these are not yet independent choices). Additional service models can be
+  easily added in modules which include Container. The "generic" model can
+  be used like "prototype" in Needle, or for manual service management.
+
+- Use mixins to build apps out of groups of services that need to coexist in
+  one name space.
+
+- Use a nested class for a group of services when you want them to live in
+  their own namespace. (See the ColorNamespace example.)
+
+- The Injectable module can be used without MinDI containers as a kind of
+  delegation:
+
+    require 'mindi'
+    x = [1,2,3]
+    y = {}
+    x.extend MinDI::Injectable
+    x.inject_into y
+    p y.reverse    # ==> [3, 2, 1]
+
+- MinDI can be used as a Rake-like task scheduler:
+
+    require 'mindi'
+
+    class Tasks
+      include MinDI::BasicContainer
+
+      a  { print "a" }
+      b  { a; print "b" }
+      c  { a; print "c" }
+      d  { b; c; print "d" }
+    end
+
+    Tasks.new.d  # ==> abcd 
+
+Bugs
+----
+
+- Private and protected services must be declared explicitly:
+
+    private :some_service
+
+  rather than by putting them in the private section of the class def.
+
+- Because of how ruby defines Proc#arity, a service defined like
+
+    sname { do_something }
+
+  with no argument list will be treated as a multikey_multiton rather than
+  as a singleton. The behavior will be the same, though.
+
+- Running ruby with the -w option will warn about 'instance variable @foo not
+  initialized'.
+
+Todo
+----
+
+- MinDI had some introspection methods ("services_by_model(m)"), but I took
+  them out to keep the lib minimal. Maybe they will be in a mixin later.
+
+- Use args passed to service point declarations to specify aspects of the
+  service model (e.g., threaded and deferred could be specified this way).
+
+- DRb services and distributed containers. Use Rinda for service discovery.
+
+- Thread safety issues.
+
+Legal and Contact Information
+-----------------------------
+
+Copyright (C) 2004-2014 Joel VanderWerf, mailto:vjoel@users.sourceforge.net.
+
+License is BSD. See [COPYING](COPYING).

data/RELEASE-NOTES

@@ -0,0 +1,26 @@
+mindi 0.5
+
+- Repackaged and released as gem.
+
+mindi 0.4
+
+- The internal names for instance variables used to store values associated
+  with services are now more obscure. Thanks to Greg Fodor for the suggestion.
+
+mindi 0.3
+
+- Allow +nil+ and +false+ as service values. This allows limited rake-like functionality--see examples/rake-alike.rb.
+
+- Can now include MinDI::BasicContainer instead of extend MinDI::Container, for convenience.
+
+- Lots of examples.
+
+mindi 0.2
+
+- Injectable containers. See examples/inject.rb. Note that including the MinDI::Injectable module not only provides this new functionality but also extends with MinDI::Container
+
+- Because of the above change, including MinDI::Injectable is now the recommended way of using MinDI.
+
+mindi 0.1
+
+- first release

data/Rakefile

@@ -0,0 +1,64 @@
+require 'rake'
+require 'rake/testtask'
+
+PRJ = "mindi"
+
+def version
+  @version ||= begin
+    require 'mindi'
+    warn "MinDI::VERSION not a string" unless MinDI::VERSION.kind_of? String
+    MinDI::VERSION
+  end
+end
+
+def tag
+  @tag ||= "#{PRJ}-#{version}"
+end
+
+desc "Run tests"
+Rake::TestTask.new :test do |t|
+  t.libs << "lib"
+  t.libs << "ext"
+  t.test_files = FileList["test/**/*.rb"]
+end
+
+desc "Commit, tag, and push repo; build and push gem"
+task :release => "release:is_new_version" do
+  require 'tempfile'
+  
+  sh "gem build #{PRJ}.gemspec"
+
+  file = Tempfile.new "template"
+  begin
+    file.puts "release #{version}"
+    file.close
+    sh "git commit --allow-empty -a -v -t #{file.path}"
+  ensure
+    file.close unless file.closed?
+    file.unlink
+  end
+
+  sh "git tag #{tag}"
+  sh "git push"
+  sh "git push --tags"
+  
+  sh "gem push #{tag}.gem"
+end
+
+namespace :release do
+  desc "Diff to latest release"
+  task :diff do
+    latest = `git describe --abbrev=0 --tags --match '#{PRJ}-*'`.chomp
+    sh "git diff #{latest}"
+  end
+
+  desc "Log to latest release"
+  task :log do
+    latest = `git describe --abbrev=0 --tags --match '#{PRJ}-*'`.chomp
+    sh "git log #{latest}.."
+  end
+
+  task :is_new_version do
+    abort "#{tag} exists; update version!" unless `git tag -l #{tag}`.empty?
+  end
+end

data/examples/JW-app-cont-injected.rb

@@ -0,0 +1,36 @@
+require 'mindi'
+
+# Jim Weirich's example, in MinDI. From Jim Weirich's article at 
+# http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc).
+
+# Note that this code does not run because it depends on undefined classes.
+
+# For the "injected" version, we assume that classes like WebApp, StockQuotes,
+# and so on are written to refer directly to "error_handler", "logger", etc.
+# The effect of injection is that these references will resolve to the
+# error_handler, logger, etc. that belong to the same container.
+#
+# In the case of DBI and Logger, which are pre-existing classes, we use the
+# more traditional approach of using argument lists to pass in references to
+# the services that they need from the container.
+
+class JWApplicationContainer
+  include MinDI::InjectableContainer
+
+  logfilename { "logfile.log" }
+  db_user     { "jim" }
+  db_password { "secret" }
+  dbi_string  { "DBI:Pg:example_data" }
+
+  app           { WebApp.new }
+  quotes        { StockQuotes.new }
+  authenticator { Authenticator.new }
+  database      { DBI.connect(dbi_string, db_user, db_password) }
+
+  logger        { Logger.new }
+  error_handler { ErrorHandler.new }
+end
+
+def create_application
+  JWApplicationContainer.new.app
+end

data/examples/JW-app-cont.rb

@@ -0,0 +1,37 @@
+require 'mindi'
+
+# Jim Weirich's example, in MinDI. From Jim Weirich's article at 
+# http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc).
+
+# Note that this code does not run because it depends on undefined classes.
+
+class JWApplicationContainer
+  include MinDI::BasicContainer
+
+  logfilename { "logfile.log" }
+  db_user     { "jim" }
+  db_password { "secret" }
+  dbi_string  { "DBI:Pg:example_data" }
+
+  app {
+    app = WebApp.new(quotes, authenticator, database)
+    app.logger = logger
+    app.set_error_handler error_handler
+    app
+  }
+
+  quotes        { StockQuotes.new(error_handler, logger) }
+  authenticator { Authenticator.new(database, logger, error_handler) }
+  database      { DBI.connect(dbi_string, db_user, db_password) }
+
+  logger { Logger.new(logfilename) }
+  error_handler {
+    errh = ErrorHandler.new
+    errh.logger = logger
+    errh
+  }
+end
+
+def create_application
+  JWApplicationContainer.new.app
+end

data/examples/coffee.rb

@@ -0,0 +1,77 @@
+# Coffee machine example taken from Jim Weirich's OSCON 2005 slides
+# and rewritten in MinDI (following Christian Neukirchen).
+
+require 'mindi'
+
+class PotSensor
+  def initialize(port)
+    @port = port
+  end
+
+  def coffee_present?
+    #...
+  end
+end
+
+class MockSensor < PotSensor; end
+
+class Heater
+  def initialize(port)
+    @port = port
+  end
+
+  def on
+    #...
+  end
+  def off
+    #...
+  end
+end
+
+class MockHeater < Heater; end
+
+class Warmer
+  # Use attr_reader instead of "inject"--advantages: Warmer is
+  # not dependent on DI framework, and the configuration of
+  # the warmer is explicit in the container definition, below,
+  # rather than using implicit, based on method names.
+  attr_reader :pot_sensor, :heater
+  
+  def initialize(h)
+    @pot_sensor = h[:pot_sensor]
+    @heater = h[:heater]
+  end
+  
+  def trigger
+    if pot_sensor.coffee_present?
+      heater.on
+    else
+      heater.off
+    end
+  end
+end
+
+
+class MarkIVConfiguration
+  include MinDI::InjectableContainer
+  
+  uninjected # avoid warnings that "class Fixnum cannot be injected into"
+  pot_sensor_io_port  {0x08F0}
+  heater_io_port      {0x08F1}
+  injected
+  
+  pot_sensor {PotSensor.new pot_sensor_io_port}
+  heater {Heater.new heater_io_port}
+  warmer {Warmer.new :heater => heater, :pot_sensor => pot_sensor}
+  # IMO, it's better to keep this information in the container def.,
+  # rather than "hide" it in the inject declarations in Warmer. Isn't
+  # that more the spirit of DI?
+end
+
+class MarkIVTestConfig < MarkIVConfiguration
+  heater {MockHeater.new}
+  pot_sensor {MockSensor.new}
+end
+
+mkiv = MarkIVConfiguration.new
+p mkiv.warmer