retroactive_module_inclusion 1.0.1 → 1.0.2

data/README.rdoc

@@ -13,8 +13,8 @@ behaviour hurts the least surprise principle, specially because if K is a
 class, then
   K.class_eval { include M }
 _does_ make all methods of M available to all classes which had previously
-inherited it. This inconsistency stems from implementation efficienty concerns
-and characterize a limitation in Ruby's object model (see {Dynamic Module Include Problem}[http://eigenclass.org/hiki/The+double+inclusion+problem]).
+inherited it. This inconsistency stems from efficienty concerns and characterize
+a limitation in Ruby's object model (see {Dynamic Module Include Problem}[http://eigenclass.org/hiki/The+double+inclusion+problem]).
 
 == AN EXAMPLE OF THE "DYNAMIC MODULE INCLUDE" PROBLEM
 
@@ -22,8 +22,7 @@ Let's begin by defining a one-method module:
 
   module Stats
     def mean
-      n = 1
-      inject {|s,k| n += 1 ; s + k }.to_f / count
+      inject(&:+) / count.to_f
     end
   end
 

data/Rakefile

@@ -3,31 +3,28 @@
 require 'rubygems'
 require 'hoe'
 
-# Hoe.plugin :compiler
-# Hoe.plugin :cucumberfeatures
-# Hoe.plugin :gem_prelude_sucks
-# Hoe.plugin :inline
-# Hoe.plugin :manifest
-# Hoe.plugin :newgem
-# Hoe.plugin :racc
-# Hoe.plugin :rubyforge
 # Hoe.plugin :website
 
 Hoe.spec 'retroactive_module_inclusion' do
-  # HEY! If you fill these out in ~/.hoe_template/Rakefile.erb then
-  # you'll never have to touch them again!
-  # (delete this comment too, of course)
-
   developer('Adriano Mitre', 'adriano.mitre@gmail.com')
   
-  self.version = '1.0.1'
+  self.version = '1.0.2'
 
   self.readme_file = 'README.rdoc'
   self.history_file = 'History.rdoc'
   self.extra_rdoc_files += ['README.rdoc', 'History.rdoc']
   self.extra_rdoc_files << ['Wishlist.rdoc'] if File.exist? 'Wishlist.rdoc'
 
-  # self.rubyforge_name = 'retroactive_module_inclusionx' # if different than 'retroactive_module_inclusion'
+  self.description = <<EOS
+This gem circumvents the "dynamic module include" (aka "double inclusion")
+problem, which is the fact that M.module_eval { include N } does not make
+the methods of module N available to modules and classes which had included
+module M beforehand, only to the ones that include it thereafter. This
+behaviour hurts the least surprise principle, specially because if K is a
+class, then K.class_eval { include M } *does* make all methods of M available
+to all classes which had previously inherited it.
+EOS
+
 end
 
 # vim: syntax=ruby

data/test/test_retroactive_module_inclusion.rb

@@ -3,8 +3,7 @@ require File.expand_path("../../lib/retroactive_module_inclusion", __FILE__)
 
 module Stats
   def mean
-    n = 1
-    inject {|s,k| n += 1 ; s + k }.to_f / count
+    inject(&:+) / count.to_f
   end
 end
 

metadata

@@ -5,8 +5,8 @@ version: !ruby/object:Gem::Version
   segments: 
   - 1
   - 0
-  - 1
-  version: 1.0.1
+  - 2
+  version: 1.0.2
 platform: ruby
 authors: 
 - Adriano Mitre
@@ -35,7 +35,7 @@ cert_chain:
   9u8N6mQNneIVRh6Xfdko/Q==
   -----END CERTIFICATE-----
 
-date: 2011-01-20 00:00:00 -02:00
+date: 2011-01-21 00:00:00 -02:00
 default_executable: 
 dependencies: 
 - !ruby/object:Gem::Dependency 
@@ -53,18 +53,15 @@ dependencies:
         version: 2.8.0
   type: :development
   version_requirements: *id001
-description: |-
+description: |
   This gem circumvents the "dynamic module include" (aka "double inclusion")
-  problem, which is the fact that
-    M.module_eval { include N }
-  does not make the methods of module N available to modules and classes which had
-  included module M beforehand, only to the ones that include it thereafter. This
+  problem, which is the fact that M.module_eval { include N } does not make
+  the methods of module N available to modules and classes which had included
+  module M beforehand, only to the ones that include it thereafter. This
   behaviour hurts the least surprise principle, specially because if K is a
-  class, then
-    K.class_eval { include M }
-  _does_ make all methods of M available to all classes which had previously
-  inherited it. This inconsistency stems from implementation efficienty concerns
-  and characterize a limitation in Ruby's object model (see {Dynamic Module Include Problem}[http://eigenclass.org/hiki/The+double+inclusion+problem]).
+  class, then K.class_eval { include M } *does* make all methods of M available
+  to all classes which had previously inherited it.
+
 email: 
 - adriano.mitre@gmail.com
 executables: []