From: David Masover <ninja@...>
Date: 2010-07-07T09:59:15+09:00
Subject: Re: extending a core class cleanly

On Monday, July 05, 2010 06:16:10 pm Fearless Fool wrote:
> David Masover wrote:
> > What kind of surprises?
> 
> Coming from conventional programming environments, one might be
> surprised when a core class suddenly acquires new methods -- e.g.
> Rails/ActiveSupport's extensions to String -- so I wanted to make sure I
> was packaging such extensions properly.

Libraries like that do tend to isolate the syntactic sugar from the utility 
code. I think the idea is that you might do this instead:

module MathStuff
  def mean(array)
    ...
  end
end

And then, in another file:

class Array
  def mean
    MathStuff.mean self
  end
end

This might be overkill, but the idea here is: If you just require 
activesupport, you get all the extensions to string. If you require 
active_support/inflector, you get all the string manipulation methods, without 
ever having to extend a string -- all your strings stay pure.

I actually don't see a problem with extending String, and I don't see what the 
conventional argument is. The _only_ potential problem is namespace conflicts 
-- if two different libraries define String#pluralize, and it means a 
different thing to each library, you've got a problem.

> > Then, probably, provide a file people can 'require' that'll do the
> > inclusion for them, maybe even make that the default.
> 
> ... or if I was feeling adventuresome, perhaps an autoload?

That only automatically works if you then extend/include it at some point. So, 
for example, it might make sense like this:

autoload :MathStuff, 'whatever'
...
[].extend MathStuff



It would be kind of wasteful here:



autoload :MathStuff, 'whatever'
class Array
  # always loads right now
  include MathStuff
end



And it'd be completely useless otherwise.