CODEWITHSUNDEEP
rubyoopmonkeypatching
mbigras
mbigras

Reputation: 8055

Organizing monkey patches

I read a blog post that recommends namespacing your monkey patches so they can be easily viewed and included.

For example:

module CoreExtensions
  module DateTime
    module BusinessDays
      def weekday?
        !sunday? && !saturday?
      end
    end
  end
end

Would go in the: lib/core_extensions/class_name/group.rb file.

It can be included in the DateTime class with the Module#include instance method (which a class inherits because a Class is a Module)

# Actually monkey-patch DateTime
DateTime.include CoreExtensions::DateTime::BusinessDays

My question is where do the include statements go? Is there a convention?

For example:

I have the following monkey patches:

# http://www.justinweiss.com/articles/3-ways-to-monkey-patch-without-making-a-mess/
module CoreExtensions
  module String
    module Cases
      def snakecase
        return self if self !~ /[A-Z]+.*/
        # http://rubular.com/r/afGWPWLRBB
        underscored = gsub(/(.)([A-Z])/, '\1_\2')
        underscored.downcase
      end

      def camelcase
        return self if self !~ /_/ && self =~ /[A-Z]+.*/
        split('_').map{ |e| e.capitalize }.join
      end
    end
  end
end

That live inside the lib/core_extensions/string/cases.rb file.

Where should I put my String.include CoreExtensions::String::Cases statement?

Also to be clear this is just a ruby project, does that make a difference?

I've tried putting it inside lib/devify.rb

require 'devify/version'
require 'devify/some_dir'
require 'devify/scaffold'
require 'devify/tree_cloner'
require 'devify/renderer'
require 'devify/project'

require 'devify/tasks/some_task'
require 'devify/tasks/bootstrap'

require 'core_extensions/string/cases'

module Devify
  String.include CoreExtensions::String::Cases
end

This works and it makes sense why it works. It's because my entire app lives inside the Devify module or namespace.

This way is also good because I'm not polluting the global namespace correct? Because I'm only monkey patching Strings that live inside Devify?

Just not sure not if this is the right way to go about it.

Upvotes: 2

Views: 345

Answers (2)

akuhn
akuhn

Reputation: 27793

It doesn't matter where you put the include call.

Calling String.include will always monkey patch the one String class that is used by all the strings in the entire object space. So best put the instruction at the top level as to not mislead readers of the code.

Monkey patching is always global.

It is a powerful feature and can be used for good.

If you are authoring a gem be aware that you're sharing a global namespace with others. The same is also true for top-level modules and even the gem name though. Shared namespaces are just a reality of shared code.

If you are looking for lexically scoped monkey patches look into the new refinement feature that was introduce with Ruby 2.

Refinements are an idea taken from Smalltalk's class boxes. Refinements are not without their own issues though, for example they lack support for introspection and reflection. Thus essentially making them stealth and unfit for production use.

If you are looking to limit the monkey patches to some string object only, consider either subclassing String or calling extend on an instance.

Upvotes: 2

gbferreira
gbferreira

Reputation: 101

Although ruby offers many ways of changing the content of a class or a method dynamically, the monkey patching can lead to big problems and strange bugs. I read this post (http://www.virtuouscode.com/2008/02/23/why-monkeypatching-is-destroying-ruby/) about why it´s a bad idea to use monkey-patching.

In summary, many things that he says make sense. When you create a monkey-patching, you are assuming that it will only works at that project, and, maybe you can create collisions and unprevisible side-effects when more libraries with similar purposes are put together.

There are cases where the benefits of the monkey-patching were awesome, like ActiveSupport way of dealing with dates manipulation by monkey-patching the Fixnum class with the ago or from_now methods, or as the method to_json. However, monkey patching should be avoided.

The point is: Ruby is an object-oriented language, and you can achieve your objectives using object composition, or any other patterns. Monkey-patching, at some way, leads you in the opposite direction of object oriented philosophy, since you add more responsibilities to an pre-existent class and increases it's public interface to serve a new funcionallity.

Besides, it's not explicit the behavior of that class and the public methods available. You cannot know, by looking at the class definition, what it makes and what is it's role at the system, and how it interact with other objects. It makes a simple task much more harder at the end.

Monkey patching makes everything much more smaller and simpler, apparently, but avoiding it makes your code much more maintanable, easier to debug, read and test, and much more elegant, since it is compliant to the "OOP" patterns.

Upvotes: 0

Related Questions