C do

a : first_name , : last_name , : favorite_color

i Enumerable

ctor { | * args | s . first_name , s . last_name = * args }

d . complete_info? { first_name && last_name && true }

d . white? . red? . blue? . black? { | color | self . favorite_color . to_s == color . to_s . chomp ( " ? " ) }

end

Foo < Enumerable f = Foo . new ( " Mike " , " Ward " ) f . first_name f . last_name f . complete_info? f . red? f . favorite_color = : red f . red?

class Object

def C ( base_class = Object , & block )

name = File . basename ( eval ( " __FILE__ " , block . binding ) , " .rb " )

klass = eval " class #{ name . capitalize } ; end; #{ name . capitalize } " , binding , __FILE__ , __LINE__

klass . class_eval ( & block )

end



def s

self

end

end



class Class

def ctor ( & block )

define_method : initialize , & block

end



def i ( mod )

include mod

end



def d

DefineHelper . new ( self )

end



def a ( * args )

attr_accessor ( * args )

end

end



class DefineHelper

def initialize ( klass )

@ klass = klass

end



def method_stack

@ method_stack ||= []

end



def method_missing ( sym , * args , & block )

method_stack << sym

if block_given?

method_stack . each do | meth |

@ klass . class_eval do

define_method meth do

instance_exec meth , & block

end

end

end

end

self

end

end





module Kernel



def instance_exec ( * args , & block )

mname = " __instance_exec_ #{ Thread . current . object_id . abs } _ #{ object_id . abs } "

Object . class_eval { define_method ( mname , & block ) }

begin

ret = send ( mname , * args )

ensure

Object . class_eval { undef_method ( mname ) } rescue nil

end

ret

end



end

For some reason, DRY and "type less" seem to have become equivalent to many in the the Ruby community. I believe that the essence of DRY is when an application change is localized to one area of the codebase. While DRY is important, it's no more important than maintainability and readability. Therefore, if logic is stored in one and only one location, but that location cannot be found or understood, you've traded maintainability and as a result have gained nothing.But, I've grown tired of this debate. No one ever wins, instead people just get tired of listening so they stop interacting. If you want to define methods of a module in a loop that later gets included in 3 classes that have nothing else in common, you have the right to do that. In fact, I'm excited about helping you.Here's how DRY your code could be.That's some DRY code, perhaps even Extremely DRY (EDRY). Code isn't any good unless it runs.It runs without problem. Dying for the implementation? No worries, here it is.Of course, any EDRY code will be write only. It would be painful to try to actually read code written in this way, but that's already true of the 150 modules that each contain only one method definition. The difference is generally it's not immediately obvious when you first look at a codebase that has been DRYed up for the sake of keystroke savings. If the implementer instead chose to utilize EDRY, I'd know what I was getting into from the first file opened.