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

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.

The problem with the mix-in solution is that if I have all these
modifiers with unique method names I can't really account for invoking
them within the test logic natively, the template code would have to
know in advance what methods it would have to invoke. Alternatively, I
could have the mix-ins all use the same method names, but they would
override one another and force each object to have at most one
"modifier." My best practical solution so far is to include all the
"modifiers" as mix-ins with unique method names, then have one
template method that would use iterate through
Object.protected_instance_methods and execute the mix-in methods.
However, this makes dealing with the four basic types of modifiers
rather difficult, I would either have to enforce method naming
conventions to allow the template code to discern when to run which
method or (hopefully) something more clever.

I did also have the idea that I could define a DATA stream block in
the highest parent "Modifier" that would allow me to read the code of
any child as if it were a string. I could then collect all the code
from the "modifiers" for a given host object into one string and then
use something like "eval 'define methodx'.concat(codeString)" to re-
define (override) an empty template method that could be executed by
native the template code. Though Im not sure how easy it might be to
only extrapolate the code from the internally defined "modifier"
methods, or the practicality of the whole idea in general. My rather
green instinct says it may just be crazy enough to work, but I wanted
to check with the community for a better idea first.

*gasp* That was a lot to explain, hopefully it all makes sense. Thanks
in advance for your input and help!