"To a guy with a hammer, everything looks like a nail."

If you are new to OOP, then it might be fun for you to give it a try and learn from your (almost inevitable) mistakes. But I'm not sure we can give you good advice without a little more information about the particular problem you are trying to solve. Maybe I'm lazy today, but I'm having trouble envisioning your problem.

Of course, chances are that someone has already written something that could be easily adaptable to your problem space -- again, you'll get better results if you give us more concrete detail.

Yeah, my original post was pretty abstract, but that was mainly because I hadn't written any code yet. =]
I'll get down to some helpful details here.

I was coming at the same problem here from a different angle, and in a slightly simplified case. The general, long, drawn out form I'm looking at is this:

#I have some variables, and some ranges.
#really it's in a tied hash somewhere.

my %hash = {  #pretend that this is my tied hash
    a => "20",
    b => "yes",
    q => "1e-14"
};
my @range_a = (1..20);
my @range_b = ("yes", "no");

#each variable of interest has a foreach loop
# to go through the values in it's range
foreach my $a (@range_a){
  $hash{a} = $a;

  #other variables may be involved.
  my $seed = srand($a + 42); 
  my $randomness = rand($seed); 
  #or a function
  func_1(%hash);

  foreach my $b (@range_b){
    $hash{b} = $b;
    my $foo = $b + $a;

    #Then, at the innermost level, do something
    #There could be any number (probably below 20)
    # of these loops.
    my $result = end_func(%hash);
  }
}
[download]

I have already solved this with a recursive function and a hash of hashes containing the tied hash keys, the ranges they need to take on, and the statements that go in each layer. This was a little ugly, though, and scoping was interesting, to say the least. I was hoping to reduce the complexity for users dealing with this by objectifying it. My vision was something like this

#create objects in my class
my $a = param_class->new(\@range_a, $statements);
my $b = param_class->new(\@range_b, $statements);

$a->loop(
   $b->loop(
     &final_sub(%hash)
   )
);
[download]

That's an ugly generalization, but hopefully that is more telling of where I was going with this rambling.
I'll be back tomorrow to talk more with you all about this.
~MB

As far as I'm concerned, data and code are a means to an end, but not something to focus on. I try to "blur my eyes" and find the *things*, and build my classes around those.

Trite, overused example: In a toy banking application, you could worry about balances and reports. Instead, I look for the *things* (account, customer) and then stick the code and data into the appropriate places. The stuff that doesn't easily go into a particular place is a flag: Either you didn't find all the things, or there are some rough edges that should be rethought to make things fit well, or it's just one of those things that doesn't fall into place. (I've never seen a large application where some stuff simply doesn't go into a nice place. Usually, it gets shoehorned into an 'Application' or 'Frobutility' class...)

--roboticus
(Who hasn't done any OO Perl, but has buckets & buckets of OO code for some other languages...)

I have been using OO Perl for a little over two years now and my 'hero' application of about 250,000 lines of Perl code is about 60% OOP, all of it running with Perl/Tk. As time permits older code is being re-factored into objects and modules. Life is so much easier with OOP. Feature requests that used to leave me living in fear and dread are now a snap!

jdtoronto

MB

I am going to throw my hat in with ptum on this one. We need more information on what you are trying to do.

The generalizations that you provided look more like a procedural approach to solving your issue than an OO approach.

What I've got is a variable name, a range of values I want it to take on, and other various and dynamic statements I want to eval within that loop before calling a coderef.

These are all programming concepts. To get to objects, you need to look beyond the code at the real life things you are modelling.

Does the variable contain a bank balance? Then maybe you'll want classes like Customer and Account and Transaction. But if it contains a height, or an acidity, or the number of oranges that fell off that tree last month, then you'll need different classes.

Or are you trying to provide a backbone of support for arbitrary variables? If so, I would probably not recommend this for a first OO project - with objects modelling concrete real world phenomena, the concrete reality is a great guide to implementation, and give you something to refer back to for every decision you make. With the very abstract the reality can (and must) guide you the same way, but it is more difficult to see the right questions to ask without having some previous experience of doing the same thing.

Hope this helps,

Hugo