decorum 0.0.1 → 0.2.0

data/CHANGELOG.md

@@ -0,0 +1,8 @@
+# 0.2.0 / 2014-01-18
+
+* [FEATURE] support/tests for immediate methods
+* better README
+
+# 0.0.1 / 2014-01-04
+
+initial release

data/README.md

@@ -1,8 +1,9 @@
 # Decorum
 
-Decorum implements lightweight decorators for Ruby, called "tasteful decorators." (See below.)
-It is very small, possibly very fast, and has no requirements outside of the standard library.
-Use it wherever.
+Decorum implements lightweight decorators
+for Ruby, called "tasteful decorators." (See below.)  It is very small,
+possibly very fast, and has no requirements outside of the standard
+library.  Use it wherever.
 
 ## Quick Start
 ```ruby
@@ -23,102 +24,204 @@ bp.respond_to?(:shoot_confetti) # ==> false
 bp.decorate(Confetti)
 bp.shoot_confetti # ==> "boom, yay"
 ```
+## About
 
-## Rationale
+[Skip to the action](#usage)
 
-Decorum decorators are in the mold of the traditional, Gang of Four style pattern, with
-a few additional conditions. They aren't a subtype of this pattern (for various reasons)
-but they agree in the following way: Decorator is a family of basic object oriented 
-patterns which (a) are implemented with composition/delegation and (b) respect the original
-public interface of the objects being decorated. As such, they're suitable for use in
-any kind of Ruby program.
+Decorum expands on the traditional Decorator concept by satisfying [a few additional 
+contraints](#tasteful_decorators). The constraints are designed to make decorators' role in your 
+overall object structure both clear and safe. More on these points below.
 
-### Isn't a Decorator like a Presenter which is like an HTML macro?
+- Object Identity: After you decorate an object, you're still dealing with that same
+object. 
+- Defers to the original interface: by default, Decorum decorators will _not_ override
+the decorated object's public methods. (Though you can instruct it to.) This is intentional.
+- Respects existing overrides of `#method_missing`
+- Decorators are unloadable
+
+By adhering to these constraints, decorators tend to do the Right Thing, i.e, integrate into existing
+applications easily, and stay out of the way when they aren't doing your bidding. Hence "[tasteful
+decorators](#tasteful_decorators)." (Not meant to imply others are tacky. The name just stuck.)
+
+In addition, Decorum provides a few helpful features:
+
+- Stackable decorators, with shared state 
+- Recursion, via `#decorated_tail`
+- Intercept/change messages
+- Build stuff entirely out of decorators
+
+As an example of how this is in use right now, suppose you're interfacing a content
+management system with an existing data application. You want to build a sidebar 
+of image links. The images are in the CMS, but their metadata are stored in the application.
+You want those systems to stay uncoupled. You can use a decorator to slap the metadata 
+on the image at runtime, e.g.,:
+
+```ruby
+image_collection = Application::ImageData.sidebar_images
+# say this returns a hash keyed by identifier:
+# { blah: { url: 'http://blah.foo/', alt: 'The Blah Conglomerate' ... }}
+images = Cms::Images.where(identifier: image_collection.keys)
+
+images.each do |img|
+  img.decorate(ImageMetaDecorator, image_collection[img.identifier])
+end
+
+images[0].url # ==> 'http://blah.foo'
+images[0].alt # ==> 'The Blah Conglomerate'
+```
 
-In Blogylvania there is considerable disagreement about what these terms entail.
-[In RefineryCMS, for example](http://refinerycms.com/guides/extending-controllers-and-models-with-decorators),
-"decorating" a class means opening it up with a `class_eval`. (In this conception, the decorator isn't even
-an _object_, which is astonishing in Ruby.)
+### Isn't a Decorator like a Presenter which is like an HTML macro?
 
-I use the terms as follows: a "presenter" is an object which 
-mediates between a model, controller, etc. and a view. A "decorator" is an object 
-which answers messages ostensibly bound for another object, and either responds on its behalf or
-lets it do whatever it was going to in the first place. 
+In Blogylvania there is some disagreement
+about what these terms entail.  [For example, in
+RefineryCMS](http://refinerycms.com/guides/extending-controllers-and-models-with-decorators),
+"decorating" a class means opening it up with a `class_eval`. (In this
+conception, the decorator isn't even an object, which is astonishing
+in Ruby.) I use the terms as follows: a "presenter" is an object which
+mediates between a model, controller, etc. and a view. A "decorator" is
+an object which answers messages ostensibly bound for another object, and
+either responds on its behalf or lets it do whatever it was going to in
+the first place. Presenters may or may not be implemented as Decorators;
+Decorators may or may not present.
 
-### What's so special about these?
+Like "traditional" (i.e., [Gang of Four](http://en.wikipedia.org/wiki/Design_Patterns)-style)
+decorator patterns, Decorum is a general purpose, object-oriented tool. Use it wherever.
 
-Decorum decorators are like GoF decorators, but they are designed to satisfy two more constraints,
-_object identity_ and _implementation consistency._
+### <a name="#tasteful_decorators"></a>Tasteful Decorators
 
 #### Object Identity
 
-In the GoF scheme, you aren't dealing with the same object after decoration. That's fine if
-it's a totally anonymous interface, but if the identity of the object is significant---if
-calling objects are storing references to them, say---it can become a problem. 
-For example, in a common Rails idiom, if you want to do this:
+Decorators, as conceived of by GoF, Python, etc., masquerade as the
+objects they decorate by responding to their interface. They are _not_ the
+original objects themselves. This may or may not be a problem, depending
+on how your app is structured. In general though, (I doubt this is news)
+it risks breaking encapsulation. Any code which stores direct references
+to the original object will have to update them to get the decorated
+behavior.  For example, in a common Rails idiom, in order to do this:
 
 ```ruby
 render @user
 ```
 
-...having already `@user = User.find(params[:id])`, you'd better remember to do this:
+...having already `@user = User.find(params[:id])`, you have to do this:
 
 ```ruby
 if latest_winners.include(@user.id)
   @user = FreeVacationCruiseDecorator.new(@user)
 end
 ```
-The controller has to update the reference for `@user` if it wants to decorate it.
-The model's decoration status has essentially become part of the controller's state.
 
+`@user` is an instance variable of the controller, but it has to be
+updated in order for the model to be decorated.  In practical terms,
+if you store multiple references to the same object, (say the
+original object is in an array somewhere, in addition to `@user`) 
+you have to update both references to get consistent behavior. The model's
+decoration status has essentially become part of the controller's state.
+
+```ruby
+users.include?(@user) # ==> true
+winning_users = users.map { |u| FreeVacationCruiseDecorator.new(u) }
+decorated = winning_users.detect { |u| u.id == @user.id } # the decorated object---should be the "same" thing
+decorated.destination # ==> "tahiti"
+@user.destination # ==> NoMethodError
+```
 In Decorum, objects use decorator classes (descendents of Decorum::Decorator) to decorate themselves:
 
 ```ruby
-if latest_winners.include?(@user.id)
-  @user.decorate(FreeVacationCruiseDecorator, because: "You are teh awesome!")
-  @user.assault_with_flashing_gifs! # # ==>= that method wasn't there before!
+users.each do |user|
+  user.decorate(FreeVacationCruiseDecorator, because: "You are teh awesome!")
 end
+
+@user.assault_with_flashing_gifs! # ==> that method wasn't there before!
 ```
 
 The "decorated object" is the same old object, because it manages all of its
 state, including its decorations. References don't need to change, 
 and state stays where it should.
 
-#### Implementation Consistency
-
-By design, Decorum decorators do not override the methods of the decorated object. In general, 
-this seems like a bad practice. Obviously, there are edge cases, which is why this will probably
-appear as an option at some point, but only with scolding. Consider: 
-
-- It risks breaking interfaces across a class. Even if the decorator respects the 
-method type, objects which are ostensibly identical (same database id, say) may differ
-in their attributes. Suppose Bob's family calls him Skippy; with a NameDecorator, you could
-have weird conditions like this:
+#### Defers to the original interface
+
+Unless instructed otherwise, Decorum will not override existing methods
+on the decorated object. In practice, this might be useful, (see below
+for how to instruct it otherwise) but from a design standpoint, it
+looks to me like an anti-pattern.  The fact that the method _needs_
+overriding implies the original object doesn't have the relevant state to
+fulfill it. The method is now spread out over two classes, that of the original
+object and that of the decorator. 
+
+The paradigm cases of decorators don't generally address this, either. Consider three
+common examples:
+
+- Adding a scrollbar to a window
+- Adding milk to a cup of coffee
+- Providing `#full_name` to an object that supplies `#first_name` and `#last_name`
+
+In all of these cases, the decorators provide some new functionality;
+they don't change the object's original implementation. Obviously, you
+shouldn't rule it out just because the common examples don't have it,
+but it's by no means an essential use of the pattern. And from a design
+perspective, it's a red flag that concerns are becoming... unseparated.
+(It also risks weird bugs by breaking transparency, i.e., you can have
+cases where `a` and `b` are literally identical, but have different 
+attributes.)
+
+When an object is decorated, Decorum inserts its own `#method_missing`
+and `#respond_to_missing?` into the object's eigenclass. Decorum's `#method_missing`
+is only consulted after the original object has abandoned the message. (When
+overriding original methods with `immediate`, each method gets its own 
+redirect in the eigenclass as well, intercepting the message before the
+original definition is found.)
+
+#### Respects existing overrides of `#method_missing`
+
+A sizeable amount of the world's total Ruby functionality is implemented
+by overriding `#method_missing`, so decorators shouldn't get in the way.
+Because Decorum intercepts messages in the objects eigenclass, it also
+respects existing overrides. If the decorator chain doesn't claim the
+message, `super` is called and lookup proceeds normally.
+
+#### Unloadable decorators
+
+Decorators can be unloaded, if necessary. (The following case illustrates
+this, and the need for callbacks, e.g., `#after_decorate`. Definitely one
+my next priorities.)
 
 ```ruby
-work.bob == home.bob
-true
-work.bob.name == home.bob.name
-false
+@bob.decorate(IsTheMole)
+@bob.revoke_security_clearances 
+# ideally this would be called automatically by IsTheMole
+# on decoration
+
+class IsTheMole < Decorum::Decorators
+  def revoke_security_clearances
+    clearances = object.decorators.select { |d| d.is_a?(SecurityClearance) }
+    clearances.each { |clearance| object.undecorate(clearance) }
+  end
+end
 ```
 
-That may sound academic, but imagine what tracking this bug down might be like.
+### Implementation
 
-- More importantly: the fact that the method _needs_ overriding implies
-the original object doesn't have the relevant state to fulfill it. This seems like evidence
-the method belonged in the decorator to begin with. 
+As in other implementations, Decorum decorators wrap another object
+to which they forward unknown messages.  In both cases, all decorators
+other than the first wrap another decorator.  Instead of wrapping the
+original object however, the first decorator in Decorum wraps an instance
+of Decorum::ChainStop. If a method reaches the bottom of the chain, this
+object throws a signal back up the stack to Decorum's `#method_missing`,
+which then calls `super.` (This is a throw/catch, not an exception,
+which would be significantly slower.)
 
-The delegation system in Decorum gives first preference to the original object. The decorator chain
-is only consulted if the original object defers the request. GoF require that Decorators respect
-the object's original interface; you could say Decorum requires that they respect the original
-implementation as well.
+See the source for more details.
 
-### Tasteful Decorators
-Decorators which satisfy the conditions stated earlier plus these two are "tasteful decorators," 
-because they stay out of the way. (It's not a comment on other implementations. The name just
-stuck.)
+## <a name="usage"></a> Usage
 
-## Usage
+First, objects need to be decoratable. You can do this for a whole class,
+by including Decorum::Decorations, or for a single object, by extending it.
+(Note: this alone doesn't change the object's method lookup. It just makes
+`#decorate` available on the object. The behavior is only changed when
+`#decorate` is called.) The easiest method is probably including 
+Decorum::Decorations at whatever point(s) of the class hierarchy you
+feel appropriate.
 
 ### Helpers
 The decorated object is accessible as either `#root` or `#object`. A helper method:
@@ -132,18 +235,14 @@ end
 
 class StyledNameDecorator < Decorum::Decorator
   def styled_name
-    parts = [:fname, :lname, :array_of_middle_names, :array_of_styles].map do |m|
-      root.send(m)
-    end.flatten
-
-    ProperOrderOfStyles.sort_and_join_this_madness(parts)
+    ProperOrderOfStyles.sort_and_join_this_madness(object)
   end
 end
 
 r = Royalty.find_by_palace_name(:bob)
 r.respond_to? :styled_name # ==> false
 r.decorate StyledNameDecorator
-r.styled_name # ==> "Duke Baron His Grace Most Potent Sir Percy Arnold Robert \"Bob\" Gorpthwaite, Esq."
+r.styled_name # ==> "His Grace Most Potent Baron Sir Percy Arnold Robert \"Bob\" Gorpthwaite, Esq."
 ```
 
 A decorator that keeps state: (code for these is in Examples)
@@ -180,6 +279,16 @@ object; this shared state can be used for a number of purposes. Finally,
 `default_attributes` lets you set class-level defaults; these will be
 preempted by options passed to the constructor.
 
+As a side note, you can disable another decorators methods thus:
+
+```ruby
+class MethodDisabler < Decorum::Decorator
+  def method_to_be_disabled(*args)
+    throw :chain_stop, Decorum::ChainStop.new
+  end
+end
+```
+
 ### Shared State
 
 When attributes are declared with `share` (or `accumulator`), they
@@ -187,7 +296,7 @@ are shared among all decorators of that class on a given object:
 if an object has three MilkDecorators, the `#milk_level`/`#milk_level=` methods
 literally access the same state on all three.
 In addition, you get `#milk_level?` and `#reset_milk_level` to
-perform self-evident functions.
+perform self-eviYou can insert this at whatever point in the dent functions.
 
 Access to the shared state is proxied first through the root object,
 and then through an instance of Decorum::DecoratedState, before
@@ -202,19 +311,15 @@ other things:
 - Serialize it, stick it in an HTML `data` attribute, and use it 
   to initailize Javascript applications
 - Store a Rails view context for rendering
-
-...or for more esoteric purposes:
-
 - Provide context-specific response selections for decorators, e.g.,
   `return current_shared_responder.message(my_condition)` 
-- Implement polymorphic factories as decorators by storing references to classes
 
 And so on. 
 
 ### `#decorated_tail`
 
-How exactly did the first MilkDecorator know to keep passing `#add_milk`
-down the chain instead of returning, you ask? In general, the decision
+How exactly did the first MilkDecorator pass `#add_milk`
+down the chain instead of returning? In general, the decision
 whether to return directly or to pass the request down the chain for further
 input rests with the decorator itself. Cumulative decorators, like the milk example,
 can be implemented in Decorum with a form of tail recursion:
@@ -242,7 +347,7 @@ The state is saved, and because it's shared among all the MilkDecorators,
 the most recent one on the chain can service the getter method
 like a normal decorated attribute.
 
-For a standard demonstration of tail recursion in Decorum, see
+For a demonstration of tail recursion in Decorum, see
 Decorum::Examples::FibonacciDecorator:
 
 ```ruby
@@ -291,15 +396,15 @@ value instead, enabling Chain of Responsibility-looking things like this:
 (sorry, no code in the examples for this one)
 
 ```ruby
-  [ErrorHandler, SuccessHandler].each do |handler|
+  handlers = condition ? [ErrorA, SuccessA] : [ErrorB, SuccessB]
+  handlers.each do |handler|
     @agent.decorate(handler)
   end
-  this_service = find_service_decorator(params) # # ==> SomeServiceHandler
+  this_service = determine_service_decorator(params) # # ==> SomeServiceHandler
   @agent.decorate(this_service)
   @agent.service_request(params)
 
   # meanwhile:
-
   class SomeServiceHandler < Decorum::Decorators
     def service_request
       status = perform_request_on(object)
@@ -316,7 +421,27 @@ You can now parameterize your responses based on whatever conditions you like,
 by loading different decorators before the request is serviced. If nobody claims
 the specialized method, your default will be returned instead.
 
-### It's Decorators All the Way Down
+### Overriding existing methods
+
+To give decorator methods preference over an objects existing methods (if you
+must) declare the method `immediate`:
+
+```ruby
+class StrongWilledDecorator < Decorum::Decorator
+  immediate :method_in_question
+
+  def method_in_question
+    "overridden"
+  end
+end
+
+x = WeakWilledClass.new
+x.method_in_question # <== "original"
+x.decorate(StrongWilledDecorator)
+x.method_in_question # <== "overridden"
+```
+
+### Decorators All the Way Down
 
 Decorum includes a class called Decorum::BareParticular, which descends from
 SuperHash. You can initialize any values you like on it, call them as methods,
@@ -325,29 +450,30 @@ feature of this class is that it can be decorated, so you can create objects
 whose interfaces are defined entirely by their decorators, and which will
 return nil by default.
 
-## to-do
+## To-do
 A few things I can imagine showing up soon:
+- Probably the most important thing is before/after callbacks for decoration
+  and undecoration.
 - Namespaced decorators, probably showing up as a method on the root object,
   e.g., `object.my_namespace.namespaced_method`
 - Thread safety: probably not an issue if you're retooling your Rails helpers,
-  but consider a use case like this:
+  but consider a case like this:
 
 ```ruby
-  10.times do
-    my_decorator = nil  # scope the name
-    @object.decorate(RequestHandler) { |d| my_decorator = d }
+  10.times do |i|
+    port = port_base + i  # 3001, 3002, 3003...
+    @server.decorate(RequestHandler, port: port ) 
     Thread.new do
-      my_decorator.listen_for_changes_to_shared_state(...)
+      @server.listen_for_changes_to_shared_state(port: port)
     end
   end
 ```
-
-- Easy subclassing of Decorum::DecoratedState
+- Easy subclassing of Decorum::DecoratedState, so you can do wacky things with it
 
 &c. I'm open to suggestion.
  
 ## Contributing
-I wrote most of this super late at night, so that would be awesome:
+I wrote most of this super late at night, (don't worry, the tests pass) so that would be awesome:
 
 1. Fork it
 2. Create your feature branch (`git checkout -b my-new-feature`)

data/decorum.gemspec

@@ -10,7 +10,7 @@ Gem::Specification.new do |spec|
   spec.email         = ["erik.cameron@gmail.com"]
   spec.description   = %q{Tasteful decorators for Ruby. Use it wherever.}
   spec.summary       = %q{Decorum implements the Decorator pattern (more or less) in a fairly unobtrusive way.}
-  spec.homepage      = ""
+  spec.homepage      = "http://erikcameron.github.io/"
   spec.license       = "MIT"
 
   spec.files         = `git ls-files`.split($/)

data/examples/strong_willed_decorator.rb

@@ -0,0 +1,25 @@
+module Decorum
+  module Examples
+    class StrongWilledDecorator < Decorum::Decorator
+      immediate :method_in_question
+      immediate :second_immediate_method, :third_immediate_method
+      immediate :fourth_immediate_method
+
+      def method_in_question
+        "overridden"
+      end
+      
+      def second_immediate_method
+        "method dos"
+      end
+      
+      def third_immediate_method
+        "method tres"
+      end
+
+      def fourth_immediate_method
+        "method quatro"
+      end
+    end
+  end
+end

data/examples/weak_willed_class.rb

@@ -0,0 +1,15 @@
+module Decorum
+  module Examples
+    class WeakWilledClass
+      include Decorum::Decorations
+
+      def method_in_question
+        "original"
+      end
+      
+      def method_missing(*args)
+        "class method_missing"
+      end
+    end
+  end
+end

data/lib/decorum/decorations.rb

@@ -73,12 +73,27 @@ module Decorum
 
       base = @_decorator_chain || Decorum::ChainStop.new
       @_decorator_chain = klass.new(base, self, options)
+
+      if klass.immediate_methods
+        immediate = Module.new do
+          klass.immediate_methods.each do |method_name|
+            define_method(method_name) do |*args, &block|
+              response = catch :chain_stop do
+                @_decorator_chain.send(__method__, *args, &block)
+              end
+              response.is_a?(Decorum::ChainStop) ? super(*args, &block) : response
+            end
+          end
+        end
+        extend immediate
+      end
+
       decorators!
       @_decorator_chain
     end
 
     def remove_from_decorator_chain(decorator)
-      return nil unless decorators.include?(decorator) 
+      return nil unless decorator.is_a?(Decorum::Decorator) && decorators.include?(decorator) 
 
       if decorator == @_decorator_chain
         @_decorator_chain = decorator.next_link

data/lib/decorum/decorator.rb

@@ -80,6 +80,15 @@ module Decorum
       def get_default_attributes
         @default_attributes || {}
       end
+      
+      # allow Decorator classes to override the decorated object's
+      # public methods (tsk tsk)
+      def immediate(*method_names)
+        @immediate_methods ||= []
+        @immediate_methods += method_names
+      end
+
+      attr_reader :immediate_methods
     end
   end
 end

data/lib/decorum/version.rb

@@ -1,3 +1,3 @@
 module Decorum
-  VERSION = "0.0.1"
+  VERSION = "0.2.0"
 end

data/spec/integration/immediate_methods_spec.rb

@@ -0,0 +1,33 @@
+require 'spec_helper'
+
+describe "When overriding original methods with .immediate" do
+  let(:base_object) { Decorum::Examples::WeakWilledClass.new }
+
+  it "has an original method" do
+    expect(base_object.method_in_question).to eq("original")
+  end
+
+  it "overrides original methods" do
+    base_object.decorate(Decorum::Examples::StrongWilledDecorator)
+    expect(base_object.method_in_question).to eq("overridden")
+  end
+
+  it "reverts to original method when decorator is unloaded" do
+    base_object.decorate(Decorum::Examples::StrongWilledDecorator)
+    base_object.undecorate(base_object.decorators.first)
+    expect(base_object.method_in_question).to eq("original")
+  end
+
+  it "stops chain on vanished method" do
+    base_object.decorate(Decorum::Examples::StrongWilledDecorator)
+    # raise on violated assumptions rather than have multiple conditions in the same test?
+    resp =  base_object.second_immediate_method 
+    unless resp == "method dos"
+      bail_message = "Bad test data: base_object doesn't have #second_immediate_method, got #{resp}"
+      raise bail_message
+    end
+
+    base_object.undecorate(base_object.decorators.first)
+    expect(base_object.second_immediate_method).to eq("class method_missing")
+  end
+end

data/spec/unit/decorator_spec.rb

@@ -15,6 +15,22 @@ describe Decorum::Decorator do
   it 'responds to .accumulator' do
     expect(Decorum::Decorator.respond_to?(:accumulator)).to be_true
   end
+
+  it 'responds to .default_attributes' do
+    expect(Decorum::Decorator.respond_to?(:default_attributes)).to be_true
+  end
+
+  it 'responds to .get_default_attributes' do
+    expect(Decorum::Decorator.respond_to?(:get_default_attributes)).to be_true
+  end
+
+  it 'responds to .immediate' do
+    expect(Decorum::Decorator.respond_to?(:immediate)).to be_true
+  end
+
+  it 'responds to .immediate_methods' do
+    expect(Decorum::Decorator.respond_to?(:immediate_methods)).to be_true
+  end
   
   describe '#decorated_state' do
     it 'defers to the root object' do
@@ -129,7 +145,7 @@ describe Decorum::Decorator do
     end 
   end
 
-  context 'when attributes via declared personally' do
+  context 'when attributes are declared personally' do
     describe '#setter' do
       it 'sets local attribute via initialize' do
         expect(decorator.name).to eq('bob')
@@ -163,4 +179,23 @@ describe Decorum::Decorator do
       expect(response).to be_a(Decorum::ChainStop)
     end
   end
+  
+  context 'when methods are declared immediate' do
+    it 'includes them in @immediate_methods' do
+      expect(Decorum::Examples::StrongWilledDecorator.immediate_methods.include?(:method_in_question)).to be_true
+    end
+    
+    it 'respects various forms of declaration' do
+      # i.e.:
+      # - it respects mulitple immediate declarations
+      # - it respects single methods or an array of methods
+      # see Examples::StrongWilledDecorator
+      methods = ["second", "third", "fourth"].map do |pre|
+        "#{pre}_immediate_method".to_sym
+      end
+
+      got_em = methods.map { |m| Decorum::Examples::StrongWilledDecorator.immediate_methods.include?(m) }.inject(:&)
+      expect(got_em).to be_true
+    end
+  end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: decorum
 version: !ruby/object:Gem::Version
-  version: 0.0.1
+  version: 0.2.0
   prerelease: 
 platform: ruby
 authors:
@@ -9,7 +9,7 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2014-01-04 00:00:00.000000000 Z
+date: 2014-01-19 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bundler
@@ -67,6 +67,7 @@ extensions: []
 extra_rdoc_files: []
 files:
 - .gitignore
+- CHANGELOG.md
 - Gemfile
 - LICENSE.txt
 - README.md
@@ -75,7 +76,9 @@ files:
 - examples/coffee.rb
 - examples/fibonacci_decorator.rb
 - examples/milk_decorator.rb
+- examples/strong_willed_decorator.rb
 - examples/sugar_decorator.rb
+- examples/weak_willed_class.rb
 - lib/decorum.rb
 - lib/decorum/bare_particular.rb
 - lib/decorum/chain_stop.rb
@@ -85,6 +88,7 @@ files:
 - lib/decorum/version.rb
 - spec/integration/coffee_spec.rb
 - spec/integration/fibonacci_spec.rb
+- spec/integration/immediate_methods_spec.rb
 - spec/spec_helper.rb
 - spec/support/decorated_state/shared_state_stub.rb
 - spec/support/decorations/decorated_object_stub.rb
@@ -100,7 +104,7 @@ files:
 - spec/unit/decorated_state_spec.rb
 - spec/unit/decorations_spec.rb
 - spec/unit/decorator_spec.rb
-homepage: ''
+homepage: http://erikcameron.github.io/
 licenses:
 - MIT
 post_install_message: 
@@ -129,6 +133,7 @@ summary: Decorum implements the Decorator pattern (more or less) in a fairly uno
 test_files:
 - spec/integration/coffee_spec.rb
 - spec/integration/fibonacci_spec.rb
+- spec/integration/immediate_methods_spec.rb
 - spec/spec_helper.rb
 - spec/support/decorated_state/shared_state_stub.rb
 - spec/support/decorations/decorated_object_stub.rb