inheritance_module_eval 1.0.3 → 1.0.4

data/.travis.yml

@@ -2,6 +2,9 @@ rvm:
   - 1.8.7
   - 1.9.2
   - 1.9.3
-  - jruby
+  - jruby-19mode
+  - jruby-18mode
+  - rbx-19mode
+  - rbx-18mode
   - ruby-head
   - ree

data/CONTRIBUTING.md

@@ -8,22 +8,7 @@ Inheritance Module Eval is an open source project. Anyone can use the code, but
 * How to contribute fixes and improvements to the core
 * Information on how to improve the documentation
 
-1. Who can Contribute?
-----------------------
-Inheritance Module Eval is an open source project and as such contributions are always welcome. Our community is one which
- encourages involvement from all developers regardless of their ability level. We ask that you be patient with the
- other members of the community and maintain a respectful attitude towards other people’s work. Open source is a
- great way to learn a new technology so don’t be afraid to jump right in, even if you are new to Ruby/Rails.
-
-2. Before you Contribute
-------------------------
-Open source projects tend to be a collaborative effort. Since many people are relying upon Inheritance Module Eval for their real
- world applications, changes to the code can have major implications. Before you write a bug fix or code a new
- feature, you should find out if anybody is interested in your proposed change. You may find that the thing you’re
- trying to “fix” is actually desired behavior. You might also discover that someone else is working on it. Either
- way you can save yourself valuable time by announcing your intentions before starting work.
-
-### 2.1. Notification via Ticket
+### Notification via Ticket
 
 You can also search existing bug reports/issues and file a new one if you do not find an issue relevant to your
  proposed change. See Filing an Issue for more details.
@@ -32,15 +17,12 @@ The important thing is that you communicate your intention in advance of doing a
  non-controversial changes do not require this approach but you can save some time by suggesting an improvement and
  having it rejected before you write a bunch of the code.
 
-3. Filing an Issue
------------------
+## Filing an Issue
+
 If you would like to file a bug report, please create an issue in our Github Issues Tracker. You should do a basic
  search of the issues database before creating a new issue to ensure that you are not creating a duplicate issue.
 
-Please do not assign labels or create new labels to your issue. We will assign the appropriate labels to ensure your
- ticket is handled in the appropriate manner.
-
-### 3.1. Providing a Patch
+### Providing a Patch
 
 If you are filing and issue and supplying a patch at the same time, please file a Pull Request instead. The pull
  request will also create an issue at the same time but its superior to just creating an issue because the code and
@@ -56,37 +38,15 @@ If the ticket already exists, however, and you want to supply a patch after the
 Github will automatically detect this commit message when you push it and link the issue. Please see the detailed
  Github Issues blog post for more details.
 
-### 3.2. Feature Requests
+### Feature Requests
 
-We’re interested in hearing your ideas for new features but creating feature requests in the Issue Tracker is not
- the proper way to ask for a feature. A feature request is any idea you have to improve the software experience that
+We’re interested in hearing your ideas for new features. A feature request is any idea you have to improve the software experience that
  is not strictly related to a bug or error of omission.
 
 Feature requests that are accompanied by source code are always welcome. In this case you should read the next
  section on Creating a Pull Request.
 
-Feature requests without accompanying code will be closed. We simply cannot respond efficiently to feature requests
- through our Issue Tracker. If you want to suggest a feature, please use the mailing list or the user voice forum.
-
-### 3.3. How We Prioritize Issues
-
-We try our best to respond to all of the questions and issues our users have. We use the following criteria to
-prioritize issues:
-
-* Does this bug effect the latest stable release?
-* Is there a patch associated with the issue?
-* Is ther a test included in the patch?
-* Has someone else verified the bug?
-* Are there details on how to reproduce the problem?
-* We give highest priority to issues where the answer is “yes” to all of these questions. Next highest priority is for
- issues that answer “yes” to most of these questions, particularly the first few criteria.
-
-You need to include a brief description of the problem and simple steps needed to reproduce it. If you fail to
- supply this minimum level of information your issue will likely be ignored.
-
-
-4. Creating a Pull Request
---------------------------
+## Creating a Pull Request
 
 If you are going to contribute code to the Inheritance Module Eval project, the best mechanism for doing this is to create a pull
  request in Github. If you’re unfamiliar with the general concept of pull requests you may want to read more on pull
@@ -94,7 +54,7 @@ If you are going to contribute code to the Inheritance Module Eval project, the
 
 If your code is associated with an existing issue then you can provide a patch instead of creating a pull request.
 
-### 4.1. Creating a Fork
+### Creating a Fork
 
 The official Inheritance Module Eval source code is maintained in Github under the AlexParamonov/inheritance_module_eval
 
@@ -102,7 +62,7 @@ You simply need to “fork” the project and then start hacking.
 
 See the Github guide on creating forks for more details.
 
-### 4.2. Topic Branches
+### Topic Branches
 
 Git branches are “cheap.” Creating branches in Git is incredibly easy and its an ideal way to isolate a specific set
  of changes. You may be fixing several things at one time but by keeping your changes isolated it will help us to
@@ -138,7 +98,7 @@ You should probably also clean up after yourself a little. The branch has been p
 
     $ git branch -D fix-css-for-error-flash
 
-### 4.3. Including a Test
+### Including a Test
 
 Ideally your pull request will also include a test that verifies a bug (or the absence of the new feature) before
  your fix and also verifies proper functionality when you are finished. Please read the Testing Guide for more
@@ -146,7 +106,7 @@ Ideally your pull request will also include a test that verifies a bug (or the a
 
 Pull requests with tests are given top priority. Failure to include a test will likely delay acceptance of your patch.
 
-### 4.4. Creating the Pull Request
+### Creating the Pull Request
 
 Once your code is ready to go and you have pushed your topic branch to Github then you are ready to create the pull
  request and notify the Inheritance Module Eval team that your contribution is ready. You do this by browsing your project in
@@ -156,6 +116,5 @@ Once your code is ready to go and you have pushed your topic branch to Github th
 The Github guide on pull requests describes this in more detail with screenshots if you’re still confused on this
  part.
 
-5 Contributing to the Documentation
------------------------------------
+## Contributing to the Documentation
 Improvements to the documentation is encouraged.

data/LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) 2011 Alexander N Paramonov
+Copyright (c) 2011-2012 Alexander N Paramonov
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
  documentation files (the "Software"), to deal in the Software without restriction,

data/README.md

@@ -1,6 +1,9 @@
 Inheritance module_eval
 =======================
-Allows to create methods with same name inside particular class/object by pushing them down by inheritance tree.
+[![Build Status](https://secure.travis-ci.org/AlexParamonov/inheritance_module_eval.png)](http://travis-ci.org/AlexParamonov/inheritance_module_eval)
+[![Gemnasium Build Status](https://gemnasium.com/AlexParamonov/inheritance_module_eval.png)](http://gemnasium.com/AlexParamonov/inheritance_module_eval)  
+
+Allows to create methods with same name inside particular class/object by pushing them down by inheritance tree.  
 So method "field" may call other "field" in same class by calling super keyword instead of just redefine it.
 
 Installation
@@ -76,7 +79,10 @@ tested with Ruby
 * 1.8.7
 * 1.9.2
 * 1.9.3
-* jruby
+* jruby-19mode
+* jruby-18mode
+* rbx-19mode
+* rbx-18mode
 * ruby-head
 * ree
 

data/inheritance_module_eval.gemspec

@@ -22,5 +22,4 @@ So method "field" may call other "field" in same class by calling super keyword
   # specify any dependencies here; for example:
   s.add_development_dependency "rspec", ">= 2.6"
   s.add_development_dependency "rake"
-  # s.add_runtime_dependency "rest-client"
 end

data/lib/inheritance_module_eval/version.rb

@@ -1,3 +1,3 @@
 module InheritanceModuleEval
-  VERSION = "1.0.3"
+  VERSION = "1.0.4"
 end

data/spec/inheritance_spec.rb

@@ -18,25 +18,18 @@ describe InheritanceModuleEval do
       }
     end
 
-    it "should delegate to module_eval" do
-      mock_module = mock(:mock_module)
-      test_class.stub(:include)
-      test_class.stub(:extend)
-      Module.stub(:new).and_return(mock_module)
-
-      mock_module.should_receive(:module_eval).once
-      InheritanceModuleEval.instance_eval_on test_class, &say_hi_block
-
-      mock_module.should_receive(:module_eval).once
-      InheritanceModuleEval.class_eval_on test_class, &say_hi_block
-    end
-
     describe "instance methods" do
+      it "should delegate to module_eval" do
+        test_class.stub(:include)
+        Module.any_instance.should_receive(:module_eval).once
+        InheritanceModuleEval.instance_eval_on test_class, &say_hi_block
+      end
+
       it "should eval a string" do
         InheritanceModuleEval.instance_eval_on test_class, say_hi_string
         test_class.new.should respond_to :say_hi
       end
-      
+
       it "should eval a block" do
         InheritanceModuleEval.instance_eval_on test_class, &say_hi_block
         test_class.new.should respond_to :say_hi
@@ -44,11 +37,18 @@ describe InheritanceModuleEval do
     end
 
     describe "class_methods" do
+      it "should delegate to module_eval" do
+        test_class.stub(:extend)
+
+        Module.any_instance.should_receive(:module_eval).once
+        InheritanceModuleEval.class_eval_on test_class, &say_hi_block
+      end
+
       it "should eval a string" do
         InheritanceModuleEval.class_eval_on test_class, say_hi_string
         test_class.should respond_to :say_hi
       end
-      
+
       it "should eval a block" do
         InheritanceModuleEval.class_eval_on test_class, &say_hi_block
         test_class.should respond_to :say_hi
@@ -144,7 +144,7 @@ describe InheritanceModuleEval do
                 "hi from method" << ", " << super
               end
             end
-            
+
             test_class.new.say_hi.should == "hi from method, hi from eval, hi from module"
           end
         end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: inheritance_module_eval
 version: !ruby/object:Gem::Version
-  version: 1.0.3
+  version: 1.0.4
   prerelease: 
 platform: ruby
 authors:
@@ -9,11 +9,11 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2012-01-13 00:00:00.000000000 Z
+date: 2012-02-21 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rspec
-  requirement: &20407580 !ruby/object:Gem::Requirement
+  requirement: &18013760 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -21,10 +21,10 @@ dependencies:
         version: '2.6'
   type: :development
   prerelease: false
-  version_requirements: *20407580
+  version_requirements: *18013760
 - !ruby/object:Gem::Dependency
   name: rake
-  requirement: &20407080 !ruby/object:Gem::Requirement
+  requirement: &18013280 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -32,7 +32,7 @@ dependencies:
         version: '0'
   type: :development
   prerelease: false
-  version_requirements: *20407080
+  version_requirements: *18013280
 description: ! 'Allows to create methods with same name inside particular class/object
   by pushing them down by inheritance tree.
 
@@ -79,7 +79,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: inheritance_module_eval
-rubygems_version: 1.8.13
+rubygems_version: 1.8.10
 signing_key: 
 specification_version: 3
 summary: inheritance safe module_eval.