From: John Carter <john.carter@...>
Date: 2007-02-14T13:51:01+09:00
Subject: Proc objects and Maintainability - a design note to self

So I use a couple of proc objects around my system.

Sort of nice in the sense that they can tell me where they were create
(File/Line number)

Sort of nice in the sense that they parcel up a bit of lexical scope
and allow me to use it elsewhen.

But I'm starting not to like them from a long term maintenance point
of view.

They're opaque. What was that scope that got parcelled? Tell me more
about this proc instance? What is the responsibility of this
particular instance? Pretty print what it knows so I can debug it...

So now I'm gently and quietly dropping them out of my system instead
of doing something like...

proc_obj = Proc.new{|a,b,c| doStuffWith(a,b,c,andD,andE,andFfromMyLexicalScope)}

I'm refactoring that to....

class SensibleNameProcObject
   def initialize( d, e, f)
     @d, @e, @f = d, e, f
   end

   def to_s
     "#{self.class}:The dowhop is #{@d} for egg #{@e} on fries #{@f}"
   end

   def call( a, b, c)
     doStuffWith(a,b,c,@d, @e, @f)
   end
end

proc_obj = SensibleNameProcObj.new( andD,andE,andFfromMyLexicalScope)

More lines of code to define, but allows me more leeway to expand
things, and thanks to duck typing, I don't (unless I want to) have to
change a single byte of client code.

Proc objects are a handy shorthand... but like many handy shorthands,
sometimes in the long term you replace them with a long hand version
for maintainability.



John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand