From: Joel VanderWerf <vjoel@...>
Date: 2009-07-07T04:47:05+09:00
Subject: Re: A define_method question

Juston wrote:
> I did think of that, and it's probably the route I wind up taking
> unwillingly. The problem is that if all the "Modifier" objects have
> their own unpredictable method names the host object doesn't know how
> to invoke them in its native (template) code.
> 
> This will probably make more sense if I explain the context with a bit
> more dept (feel free to skip to the next paragraph.) I'm writing some
> automated testing software that will use Watir to interact with a
> browser dynamically, this stuff will be run nightly with no user
> present to direct it. The program builds a set of objects that define
> basic behavior from an input file filled with a problem-specific
> domain language. The fundamental objects are "TestSuite," "Test," ...
> "Step" and "Action." Any of these objects is subject to be changed by
> a "Modifier" that would alter the way the host object would say handle
> an error or record runtime or reset all children objects after its run
> etc. This means that most of the objects created during runtime are
> singletons in the sense that no two are ever really exactly the same,
> though they all come from the same templates. The further complicate
> the problem there are four basic types of modifiers that can be added
> at anytime: Ones that run before the template code executes, ones that
> run after the template code executes, ones that handle exceptions, and
> ones that run every time the host object becomes the focus of the
> stack. Modifiers are sporadically defined in the domain language (and
> subsequent ruby code module) added and removed without any regard to
> the underlying code, their presence is largely masked from the logic
> of the main system.

I'd still avoid eval-ing code and try to use data structures of procs, 
something like this:

class Action
   def some_template
     before.each {|pr| pr.call(self)}
     puts "in template code"
     after.each {|pr| pr.call(self)}
   end

   def before
     @before ||= []
   end

   def after
     @after ||= []
   end
end

a = Action.new
a.before << proc {puts "before 1"}
a.before << proc {puts "before 2"}
a.after << proc {puts "after"}

a.some_template

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407