From: Juston <justondavies@...>
Date: 2009-07-07T05:47:21+09:00
Subject: Re: A define_method question

That looks pretty sharp actually, after reading more about proc
objects I think that may be the way to go. A lot cleaner than one
giant define on a conglomerate string and a bit more flexible.
Also, it looks like Ruby2Ruby and ParseTree (or ruby_parser) is going
to help me get what I need from the "Modifier" objects too. I still
need to do some more reading before I fully understand how to use it.
If anyone has a good guide let me know, otherwise I'll hit the search
engines.

Thanks for the help and excellent input, this saves me a lot of time
and headache!

On Jul 6, 1:47 pm, Joel VanderWerf <vj...@path.berkeley.edu> wrote:
> 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