From: James Edward Gray II <james@...>
Date: 2009-11-15T07:10:52+09:00
Subject: Re: Naming conventions -- was: Re: DRYing a Regex

On Nov 14, 2009, at 3:22 PM, Marnen Laibow-Koser wrote:

> James Edward Gray II wrote:
>> Hopefully I've made my case by now, but just to sum it up one more time: 
>> I think it's more flexible than subclassing, 
> 
> Even subclassing like
> class SpecialString < String
>  include SpecialModule
> end
> ?
> 
> It seems to me that this is the best of both worlds.

It seems to me like an extra step that isn't needed.  :)

Obviously, this does work too, yes.

About the only downside I can think of now is that using this technique, I need to be in control of the code where the object is created.  In other words, I need to make sure that code does SpecialString.new() instead of String.new() (or using a String literal).  I guess I could still mix the module into an object after the fact, but that raises the excellent question of what is the class doing here?

>> it can be documented.  
> 
> How can it be documented?  In the example I gave above, the rdoc for 
> SpecialString will say that it includes SpecialModule.  I don't see how 
> to do that with a singleton mixin.

It fits into RDoc comments naturally:

# Returns an Array enhanced by the Paginated module.
def paginate(…)
  …
end

# This module is used to add pagination support to objects…
module Paginated
  …
end

>> I'm not seeing the minuses.
> 
> Start with the lack of documentation.

OK, I answered that.

Now you answer the question you ignored, what about the well-known issue of inheritance producing tight coupling.  :)  Here's a link to a good description of the problem, from a Java point of view:

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

James Edward Gray II