“Han Holl” email@example.com schrieb im Newsbeitrag
“Robert Klemme” firstname.lastname@example.org wrote in message >
I wonder though what you are trying to achieve. It looks quite
complicated to me and currently I don’t have a clue about the real world
problem you are trying to solve.
You’re right, it’s quite complicated.
I need to repeat your statements to be sure I got you correctly.
We had a data-entry program where people who weren’t necessarily
programmers could write end-of-text-field validation functions in a very
programming language that looked a lot like awk, but with multidimensional
We are going to replace this language with a subset of ruby.
So, people will write the functions using Ruby sytax in the future?
I am trying to create an environment that resembles the environment they
used to. They will be able to write functions that are all evaluated into
the same class.
If I do understand correctly, you end up with a single class that has a
bunch of methods and these methods are the ones your people will write.
These ruby functions will be called with a lot of environment
predefined. A typical end-function could look like:
value =~ /\d\d-\d\d-\d\d/
This one apparently doesn’t use any environmental data. (Btw, you might
want to add “^” and “$” to that function.)
These end-functions are alse able to fill-in other fields, do code
and so on.
Aha, so the instance of your class at hand has instance variables and
predefined methods that some of the functions can use.
In an configuration file you can specify which functions will be called
An important part of this is to make it look as familiar to them as I can,
but still have the advantage of using ruby with all of it’s wondeful
So, basically there are two interfaces for your people: the piece where they
define the functions and the config file where they define the concrete
invocation order of functions.
And it seems, you want to keep the config file syntax while changing the
sytax that the function definition interface (or file?) uses to Ruby. So
basically you parse the config file and generate a method that reflects
invocation sequence of the other methods. Something like that.
I guess, I got the broad picture. Now I’m just missing the connection to
the original problem.