super_module 1.2.1 → 1.2.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 68d5daba9c77fe5ee84f024856002607eaa567fb
-  data.tar.gz: 0fdb3c4950a1ffa2fea44970561c2c688a355fb1
+  metadata.gz: 80fcc01874eafdb2bf870cd3e06f55a135d830d1
+  data.tar.gz: 7c9b6e1a8b5f16b19ff60755c2258b3e67da3484
 SHA512:
-  metadata.gz: ad5348c682aa493a0a22196b16c976e8bbeb1708aaf912503408bc4731eba158009ce44100237be0c5843848fcbf85f77a289656a5e686e14990238c98594c09
-  data.tar.gz: c5727909276e62bbff1e9ac82399cefb683a089c17b5a017924a66b6b4794555746a3add17b0731f03f3f4c71b358f96b7367c70acfea3a71fa21c217428817e
+  metadata.gz: e0f9ac72e8ae4aaf4fee64d9aaae54a996de85d7e18b3f5de523bef20bc0b1362bca31bc3317888fe1de405468cc43ef117de47098792ffbb98642deb42de3d5
+  data.tar.gz: 9e0dd6a4468c5719a99197a2136c4a9b5078009c2b78aa5fb0feb5674f322b2020648658fa279bd43caad6b68074f32eeb2e2836c23927d61c428dcd4985b9d3

data/README.md

@@ -1,12 +1,11 @@
-# <img src="https://raw.githubusercontent.com/AndyObtiva/super_module/master/SuperModule.jpg" alt="SuperModule" align="left" height="50" /> &nbsp; SuperModule 2 Beta (1.2.1)
+# <img src="https://raw.githubusercontent.com/AndyObtiva/super_module/master/SuperModule.jpg" alt="SuperModule" align="left" height="50" /> &nbsp; SuperModule 2 Beta
 [![Gem Version](https://badge.fury.io/rb/super_module.svg)](http://badge.fury.io/rb/super_module)
-[![Build Status](https://api.travis-ci.org/AndyObtiva/super_module.svg?branch=master)](https://travis-ci.org/AndyObtiva/super_module)
 [![Coverage Status](https://coveralls.io/repos/AndyObtiva/super_module/badge.svg?branch=master)](https://coveralls.io/r/AndyObtiva/super_module?branch=master)
 [![Code Climate](https://codeclimate.com/github/AndyObtiva/super_module.svg)](https://codeclimate.com/github/AndyObtiva/super_module)
 
-Calling [Ruby](https://www.ruby-lang.org/en/)'s [`Module#include`](http://ruby-doc.org/core-2.2.1/Module.html#method-i-include) to mix in a module does not bring in class methods by default. This can come as quite the surprise when attempting to include class methods via a module. 
+Calling [Ruby](https://www.ruby-lang.org/en/)'s [`Module#include`](http://ruby-doc.org/core-2.2.1/Module.html#method-i-include) to mix in a module does not bring in class methods by default. This can come as quite the surprise when attempting to include class methods via a module.
 
-Ruby offers one workaround in the form of implementing the hook method [`Module.included(base)`](http://ruby-doc.org/core-2.2.1/Module.html#method-i-included) [following a certain boilerplate code idiom](http://www.railstips.org/blog/archives/2009/05/15/include-vs-extend-in-ruby/). Unfortunately, it hinders code maintainability and productivity with extra unnecessary complexity, especially in production-environment projects employing many [mixins](http://en.wikipedia.org/wiki/Mixin) (e.g. modeling business domain models with composable object [traits](http://en.wikipedia.org/wiki/Trait_(computer_programming))). 
+Ruby offers one workaround in the form of implementing the hook method [`Module.included(base)`](http://ruby-doc.org/core-2.2.1/Module.html#method-i-included) [following a certain boilerplate code idiom](http://www.railstips.org/blog/archives/2009/05/15/include-vs-extend-in-ruby/). Unfortunately, it hinders code maintainability and productivity with extra unnecessary complexity, especially in production-environment projects employing many [mixins](http://en.wikipedia.org/wiki/Mixin) (e.g. modeling business domain models with composable object [traits](http://en.wikipedia.org/wiki/Trait_(computer_programming))).
 
 Another workaround is [`ActiveSupport::Concern`](http://api.rubyonrails.org/classes/ActiveSupport/Concern.html), a Rails library that attempts to ease some of the boilerplate pain by offering a [DSL](http://www.infoq.com/news/2007/06/dsl-or-not) layer on top of [`Module.included(base)`](http://ruby-doc.org/core-2.2.1/Module.html#method-i-included). Unfortunately, while it helps improve readability a bit, it adds even more boilerplate idiom cruft, thus feeling no more than putting a band-aid on the problem.
 
@@ -30,13 +29,13 @@ module UserIdentifiable
       validates :user_id, presence: true
     end
   end
-  
+
   module ClassMethods
     def most_active_user
       User.find_by_id(select('count(id) as head_count, user_id').group('user_id').order('count(id) desc').first.user_id)
     end
   end
-  
+
   def slug
     "#{self.class.name}_#{user_id}"
   end
@@ -56,13 +55,13 @@ module UserIdentifiable
     belongs_to :user
     validates :user_id, presence: true
   end
-  
+
   module ClassMethods
     def most_active_user
       User.find_by_id(select('count(id) as head_count, user_id').group('user_id').order('count(id) desc').first.user_id)
     end
   end
-  
+
   def slug
     "#{self.class.name}_#{user_id}"
   end
@@ -76,7 +75,7 @@ A step forward that addresses the boiler-plate repetitive code concern, but is o
 ```ruby
 super_module :UserIdentifiable do
   include ActiveModel::Model
-  
+
   belongs_to :user
   validates :user_id, presence: true
 
@@ -110,7 +109,7 @@ end
 
 <b>Using [Bundler](http://bundler.io/)</b>
 
-Add the following to Gemfile: <pre>gem 'super_module', '1.0.0'</pre>
+Add the following to Gemfile: <pre>gem 'super_module', '1.2.2'</pre>
 
 And run the following command: <pre>bundle</pre>
 
@@ -204,7 +203,7 @@ super_module :RequiresAttributes do
   def self.required_attributes
     @required_attributes ||= []
   end
-  
+
   def requirements_satisfied?
     !!self.class.required_attributes.reduce(true) { |result, required_attribute| result && send(required_attribute) }
   end
@@ -272,16 +271,16 @@ V2 has a much simpler algorithm than V1 that goes as follows:
 
  * [SuperModule](https://rubygems.org/gems/super_module) has been designed to be used only in the initial code definition of a module (not supporting later re-opening of the module.)
 
- * Given [SuperModule](https://rubygems.org/gems/super_module)'s implementation relies on `self.included(base)`, if an including super module (or a super module including another super module) must hook into <code>self.included(base)</code> for meta-programming cases that require it, such as conditional `include` statements or method definitions, it would have to alias <code>self.included(base)</code> and then invoke the aliased version in every super module that needs it like in this example: 
-```ruby 
+ * Given [SuperModule](https://rubygems.org/gems/super_module)'s implementation relies on `self.included(base)`, if an including super module (or a super module including another super module) must hook into <code>self.included(base)</code> for meta-programming cases that require it, such as conditional `include` statements or method definitions, it would have to alias <code>self.included(base)</code> and then invoke the aliased version in every super module that needs it like in this example:
+```ruby
 super_module :AdminIdentifiable do
     include UserIdentifiable
-    
+
     class << self
         alias included_super_module included
         def included(base)
             included_super_module(base)
-            # do some extra work 
+            # do some extra work
             # like conditional inclusion of other modules
             # or conditional definition of methods
         end
@@ -292,6 +291,10 @@ In the future, [SuperModule](https://rubygems.org/gems/super_module) could perha
 
 ## What's New?
 
+### v2 Beta (v1.2.2)
+
+* Relaxed dependency on `method_source` gem version
+
 ### v2 Beta (v1.2.1)
 
 * Standalone super module usage (e.g. direct class method invocation)
@@ -316,11 +319,11 @@ In the future, [SuperModule](https://rubygems.org/gems/super_module) could perha
  * New dependency on [Banister](https://github.com/banister)'s [method_source](https://github.com/banister/method_source) library to have the self-friendly algorithm eval inherited class method sources into the including base class or module.
  * Refactorings, including break-up of the original SuperModule into 3 modules in separate files
  * More RSpec test coverage, including additional method definition scenarios, such as when adding dynamically via `class_eval` and `define_method`
- 
+
 ## Feedback and Contribution
 
 [SuperModule](https://rubygems.org/gems/super_module) is written in a very clean and maintainable test-first approach, so you are welcome to read through the code on GitHub for more in-depth details:
-https://github.com/AndyObtiva/super_module 
+https://github.com/AndyObtiva/super_module
 
 The library is quite new and can use all the feedback and help it can get. So, please do not hesitate to add comments if you have any, and please fork [the project on GitHub](https://github.com/AndyObtiva/super_module#fork-destination-box) in order to [make contributions via Pull Requests](https://github.com/AndyObtiva/super_module/pulls).
 

data/VERSION

@@ -1 +1 @@
-1.2.1
+1.2.2

data/super_module.gemspec

@@ -2,16 +2,16 @@
 # DO NOT EDIT THIS FILE DIRECTLY
 # Instead, edit Jeweler::Tasks in Rakefile, and run 'rake gemspec'
 # -*- encoding: utf-8 -*-
-# stub: super_module 1.2.1 ruby lib
+# stub: super_module 1.2.2 ruby lib
 
 Gem::Specification.new do |s|
   s.name = "super_module".freeze
-  s.version = "1.2.1"
+  s.version = "1.2.2"
 
   s.required_rubygems_version = Gem::Requirement.new(">= 0".freeze) if s.respond_to? :required_rubygems_version=
   s.require_paths = ["lib".freeze]
   s.authors = ["Andy Maleh".freeze]
-  s.date = "2017-10-23"
+  s.date = "2019-08-06"
   s.description = "SuperModule allows defining class methods and method invocations the same way a super class does without using def included(base). This also succeeds ActiveSupport::Concern by offering lighter syntax".freeze
   s.extra_rdoc_files = [
     "LICENSE.txt",
@@ -61,7 +61,7 @@ Gem::Specification.new do |s|
     s.specification_version = 4
 
     if Gem::Version.new(Gem::VERSION) >= Gem::Version.new('1.2.0') then
-      s.add_runtime_dependency(%q<method_source>.freeze, ["~> 0.8.2"])
+      s.add_runtime_dependency(%q<method_source>.freeze, [">= 0.8.2"])
       s.add_development_dependency(%q<jeweler>.freeze, ["~> 2.3.0"])
       s.add_development_dependency(%q<rdoc>.freeze, ["~> 4.2.0"])
       s.add_development_dependency(%q<rspec>.freeze, ["~> 3.2.0"])
@@ -71,7 +71,7 @@ Gem::Specification.new do |s|
       s.add_development_dependency(%q<tins>.freeze, ["~> 1.6.0"])
       s.add_development_dependency(%q<term-ansicolor>.freeze, ["~> 1.3.2"])
     else
-      s.add_dependency(%q<method_source>.freeze, ["~> 0.8.2"])
+      s.add_dependency(%q<method_source>.freeze, [">= 0.8.2"])
       s.add_dependency(%q<jeweler>.freeze, ["~> 2.3.0"])
       s.add_dependency(%q<rdoc>.freeze, ["~> 4.2.0"])
       s.add_dependency(%q<rspec>.freeze, ["~> 3.2.0"])
@@ -82,7 +82,7 @@ Gem::Specification.new do |s|
       s.add_dependency(%q<term-ansicolor>.freeze, ["~> 1.3.2"])
     end
   else
-    s.add_dependency(%q<method_source>.freeze, ["~> 0.8.2"])
+    s.add_dependency(%q<method_source>.freeze, [">= 0.8.2"])
     s.add_dependency(%q<jeweler>.freeze, ["~> 2.3.0"])
     s.add_dependency(%q<rdoc>.freeze, ["~> 4.2.0"])
     s.add_dependency(%q<rspec>.freeze, ["~> 3.2.0"])

metadata

@@ -1,27 +1,27 @@
 --- !ruby/object:Gem::Specification
 name: super_module
 version: !ruby/object:Gem::Version
-  version: 1.2.1
+  version: 1.2.2
 platform: ruby
 authors:
 - Andy Maleh
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2017-10-23 00:00:00.000000000 Z
+date: 2019-08-06 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: method_source
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: 0.8.2
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: 0.8.2
 - !ruby/object:Gem::Dependency