inheritance_module_eval 1.0.2 → 1.0.3

data/.gitignore

@@ -2,12 +2,21 @@
 .bundle
 Gemfile.lock
 pkg/*
-.idea/
+.idea/*
 doc/
-log/*.log
-/tmp/
-tmp/
+log/*
+tmp/*
 db/*.sqlite3
 /coverage
 /coverage.data
 /.yardoc
+.rvmrc
+
+## generic files to ignore
+*~
+*.lock
+*.DS_Store
+*.swp
+*.out
+*.swo
+*.md.html

data/CONTRIBUTING.md

@@ -0,0 +1,161 @@
+Contributing to Inheritance Module Eval
+==========================
+Inheritance Module Eval is an open source project. Anyone can use the code, but more importantly, anyone can contribute. This is a
+ group effort and we value your input. Please consider making a contribution to help improve the Inheritance Module Eval. This
+ guide covers:
+
+* How to file a ticket when you discover a bug
+* 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
+
+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.
+
+The important thing is that you communicate your intention in advance of doing a lot of work. Simple bug fixes and
+ 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
+-----------------
+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
+
+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
+ issue can be linked.
+
+If the ticket already exists, however, and you want to supply a patch after the fact,
+ you can simply reference the issue number in your commit message. For example, if your commit fixed issue #123 you
+ could use the following commit message:
+
+    Fixed a problem with Facebook authentication.
+
+    [Fixes #123]
+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
+
+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
+ 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
+--------------------------
+
+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
+ requests in Github.
+
+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
+
+The official Inheritance Module Eval source code is maintained in Github under the AlexParamonov/inheritance_module_eval
+
+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
+
+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
+ find and apply only the changes we’re interested in. You should create a clean branch based on the latest
+ inheritance_module_eval/master when doing this. It is important you follow these steps exactly,
+ it will prevent you from accidentally including unrelated changes from your local repository into the branch.
+
+For example, if we were submitting a patch to fix an issue with the CSS in the flash error message you could create
+ a branch as follows:
+
+    $ git remote add upstream git://github.com/AlexParamonov/inheritance_module_eval.git
+    $ git fetch upstream
+    $ git checkout -b fix-css-for-error-flash --track upstream/master
+
+The fetch command will grab all of the latest commits from the Inheritance Module Eval master branch. Don’t worry,
+ it doesn’t alter your working repository in a harmful way. The track part of the command will tell git that this
+ branch should track with the remote version of the upstream master. This is another way of saying that the branch
+ should be based on a clean copy of the latest official source code (without any of your unrelated local changes.)
+
+You can then do work locally on this topic branch and push it up to your Github fork when you are done. So in our
+ previous example we do something like:
+
+    $ git push origin fix-css-for-error-flash
+
+Of course if you want the fix for yourself to use in your own local code you should probably merge it down to your
+ own personal master branch that you’re using for development
+
+    $ git checkout master
+    $ git merge fix-css-for-error-flash
+
+You should probably also clean up after yourself a little. The branch has been pushed to Github and you’ve merged it
+  locally so you don’t really need a local copy of the branch laying around.
+
+    $ git branch -D fix-css-for-error-flash
+
+### 4.3. 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
+ information on writing and running your tests.
+
+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
+
+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
+ Github and changing to the topic branch you just pushed. Once you are on the topic branch simply create a pull
+ request by pressing the “Pull Request” button.
+
+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
+-----------------------------------
+Improvements to the documentation is encouraged.

data/LICENSE

@@ -1,7 +1,16 @@
 Copyright (c) 2011 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, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+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,
+ including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,
+ subject to the following conditions:
 
-The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the
+Software.
 
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+ IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.md

@@ -1,11 +1,11 @@
 Inheritance module_eval
 =======================
-Inheritance module_eval saves inheritance structure of dynamically created methods.
-Allows to redefine dynamic method in the same class or in any child class, and call original method by super keyword
+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
 ------------
-    gem inheritance_module_eval
+    gem install inheritance_module_eval
 
 Usage
 -----
@@ -33,6 +33,7 @@ Below is some simple example of inheritance_module_eval usage:
 
     # Some dummy class that uses #instance_module_eval
     class Content
+      # defines simple getter and setter
       self.field(name)
         instance_module_eval %{
           def #{name}
@@ -53,8 +54,9 @@ Below is some simple example of inheritance_module_eval usage:
       field :content
       field :etc
 
+      # you desided, that title for article should be titelized
+      # from now you dont need to call alias_method or reimplement method anymore!
       # you can use inheritance!
-      # you dont need to call alias_method anymore!
       # make it simple
       def title
         super.to_s.titelize
@@ -80,6 +82,11 @@ tested with Ruby
 
 see [build history](http://travis-ci.org/#!/AlexParamonov/inheritance_module_eval/builds)
 
+Contributing
+-------------
+see [contributing guide](http://github.com/AlexParamonov/inheritance_module_eval/blob/master/CONTRIBUTING.md)
+
 Copyright
 ---------
-Copyright © 2011 Alexander N Paramonov. See LICENSE for details.
+Copyright © 2011-2012 Alexander N Paramonov.
+Released under the MIT License. See the LICENSE file for further details.

data/Rakefile

@@ -1,5 +1,12 @@
+# encoding: utf-8
+# GEMS
 require "bundler/gem_tasks"
-require 'rspec'
+
+# SPECS
+require 'rspec/core'
 require 'rspec/core/rake_task'
-RSpec::Core::RakeTask.new(:spec)
-task :default => [:spec]
+RSpec::Core::RakeTask.new(:spec) do |spec|
+  spec.pattern = FileList['spec/**/*_spec.rb']
+end
+#Rake::Task["spec"].execute
+task :default => :spec

data/inheritance_module_eval.gemspec

@@ -9,8 +9,8 @@ Gem::Specification.new do |s|
   s.email       = ["alexander.n.paramonov@gmail.com"]
   s.homepage    = "http://github.com/AlexParamonov/inheritance_module_eval"
   s.summary     = %q{inheritance safe module_eval.}
-  s.description = %q{saves inheritance structure of dynamically created methods.
-Allows to redefine dynamic method in the same class or in any child class, and call original method by super keyword}
+  s.description = %q{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.}
 
   s.rubyforge_project = "inheritance_module_eval"
 

data/lib/inheritance_module_eval/version.rb

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

data/spec/inheritance_spec.rb

@@ -1,79 +1,57 @@
 require "inheritance_module_eval"
 
-class Parent
-
-end
-
-class Child < Parent
-
-end
 describe InheritanceModuleEval do
   describe "add dynamic methods" do
-    before(:each) do
-      @test_object = Class.new
+    let(:test_class){ Class.new }
+    let(:say_hi_block) do
+      Proc.new do
+        def say_hi
+          "hi"
+        end
+      end
+    end
+    let(:say_hi_string) do
+      %{
+        def say_hi
+          'hi'
+        end
+      }
     end
 
     it "should delegate to module_eval" do
       mock_module = mock(:mock_module)
-      @test_object.stub(:include)
-      @test_object.stub(:extend)
+      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_object do
-        def say_hi
-          puts hi
-        end
-      end
+      InheritanceModuleEval.instance_eval_on test_class, &say_hi_block
 
       mock_module.should_receive(:module_eval).once
-
-      InheritanceModuleEval.class_eval_on @test_object do
-        def say_hi
-          puts hi
-        end
-      end
+      InheritanceModuleEval.class_eval_on test_class, &say_hi_block
     end
 
     describe "instance methods" do
       it "should eval a string" do
-        InheritanceModuleEval.instance_eval_on @test_object, %{
-                                                                def say_hi
-                                                                  puts 'hi'
-                                                                end
-                                                              }
-          @test_object.new.should respond_to :say_hi
-
+        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_object do
-          def say_hi
-            puts 'hi'
-          end
-        end
-        @test_object.new.should respond_to :say_hi
+        InheritanceModuleEval.instance_eval_on test_class, &say_hi_block
+        test_class.new.should respond_to :say_hi
       end
     end
 
     describe "class_methods" do
       it "should eval a string" do
-        InheritanceModuleEval.class_eval_on @test_object do
-          def say_hi
-            puts 'hi'
-          end
-        end
-
-        @test_object.should respond_to :say_hi
+        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_object do
-          def say_hi
-            puts 'hi'
-          end
-        end
-
-        @test_object.should respond_to :say_hi
+        InheritanceModuleEval.class_eval_on test_class, &say_hi_block
+        test_class.should respond_to :say_hi
       end
     end
 
@@ -82,27 +60,20 @@ describe InheritanceModuleEval do
       describe "define already defined method in a class" do
         context "redefine it after class declaration" do
           it "should has lower priority then method, declared in a class" do
-            klass = Class.new
-            klass.class_eval do
-              def say_hi
-                "hi from method" << " " << super
-              end
-            end
-
-            InheritanceModuleEval.instance_eval_on klass do
+            test_class.class_eval do
               def say_hi
-                "hi from eval"
+                "hi from method" << " and just super " << super
               end
             end
 
-            klass.new.say_hi.should == "hi from method hi from eval"
+            InheritanceModuleEval.instance_eval_on test_class, &say_hi_block
+            test_class.new.say_hi.should == "hi from method and just super hi"
           end
         end
 
         context "redefine it before class declaration" do
           it "should has lower priority then method, declared in a class" do
-            klass = Class.new
-            klass.class_eval do
+            test_class.class_eval do
               InheritanceModuleEval.instance_eval_on self do
                 def say_hi
                   "tiny hi"
@@ -113,14 +84,13 @@ describe InheritanceModuleEval do
                 super.upcase
               end
             end
-            klass.new.say_hi.should == "TINY HI"
+            test_class.new.say_hi.should == "TINY HI"
           end
         end
 
         describe "redefine as much as you want" do
-          it "should push dynamic method up in the inheritance tree" do
-            klass = Class.new
-            klass.class_eval do
+          it "should push dynamic method down by the inheritance tree" do
+            test_class.class_eval do
               InheritanceModuleEval.instance_eval_on self do
                 def say_hi
                   [5]
@@ -149,7 +119,7 @@ describe InheritanceModuleEval do
                 [1] + super
               end
             end
-            klass.new.say_hi.should == [1, 2, 3, 4, 5]
+            test_class.new.say_hi.should == [1, 2, 3, 4, 5]
           end
         end
 
@@ -158,24 +128,24 @@ describe InheritanceModuleEval do
             test_module = Module.new
             test_module.module_eval do
               def say_hi
-                ["hi from module"]
+                "hi from module"
               end
             end
 
-            klass = Class.new
-            klass.class_eval do
+            test_class.class_eval do
               include test_module
               InheritanceModuleEval.instance_eval_on self do
                 def say_hi
-                  ["hi from eval"] + super
+                  "hi from eval" << ", " << super
                 end
               end
 
               def say_hi
-                ["hi from method"] + super
+                "hi from method" << ", " << super
               end
             end
-            klass.new.say_hi.should == ["hi from method", "hi from eval", "hi from module"]
+            
+            test_class.new.say_hi.should == "hi from method, hi from eval, hi from module"
           end
         end
       end
@@ -184,7 +154,7 @@ describe InheritanceModuleEval do
 
     describe "#get_module_for" do
       it "should return Module" do
-        InheritanceModuleEval.send :get_module_for, "'hi'"
+        expect{ InheritanceModuleEval.send :get_module_for, "'hi'"}.to_not raise_error
       end
 
       it "should raise ArgumentError if no code given" do

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: inheritance_module_eval
 version: !ruby/object:Gem::Version
-  version: 1.0.2
+  version: 1.0.3
   prerelease: 
 platform: ruby
 authors:
@@ -9,11 +9,11 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2011-11-14 00:00:00.000000000Z
+date: 2012-01-13 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rspec
-  requirement: &12174720 !ruby/object:Gem::Requirement
+  requirement: &20407580 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -21,10 +21,10 @@ dependencies:
         version: '2.6'
   type: :development
   prerelease: false
-  version_requirements: *12174720
+  version_requirements: *20407580
 - !ruby/object:Gem::Dependency
   name: rake
-  requirement: &12174300 !ruby/object:Gem::Requirement
+  requirement: &20407080 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -32,11 +32,12 @@ dependencies:
         version: '0'
   type: :development
   prerelease: false
-  version_requirements: *12174300
-description: ! 'saves inheritance structure of dynamically created methods.
+  version_requirements: *20407080
+description: ! 'Allows to create methods with same name inside particular class/object
+  by pushing them down by inheritance tree.
 
-  Allows to redefine dynamic method in the same class or in any child class, and call
-  original method by super keyword'
+  So method "field" may call other "field" in same class by calling super keyword
+  instead of just redefine it.'
 email:
 - alexander.n.paramonov@gmail.com
 executables: []
@@ -46,6 +47,7 @@ files:
 - .gitignore
 - .rspec
 - .travis.yml
+- CONTRIBUTING.md
 - Gemfile
 - HISTORY.md
 - LICENSE
@@ -77,9 +79,8 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: inheritance_module_eval
-rubygems_version: 1.8.11
+rubygems_version: 1.8.13
 signing_key: 
 specification_version: 3
 summary: inheritance safe module_eval.
 test_files: []
-has_rdoc: