Re: Design Question

You could create the array in processA() / processB() and pass a reference to it to commonStuff() as a parameter:

processAorB ....{
   my @commonArray;
   commonStuff( \@commonArray, \%other, \$variables );
   ...
}
sub commonStuff {
   my ( $commonArrayRef, $hash, $var ) = @_;
   if ( $commonArrayRef->[0] > 37 ) { ...
 
   }
}
[download]

As you can see, accessing the $commonArrayRef contents is just like handling the array itself, except for sticking an arrow in the middle. There's only one array, it's only a reference which is passed around, rather than copying the array, so function calls are faster, and any changes to the array within commonStuff() is visible where it is called.

If you don't need the array outside commonStuff(), you can use a closure. The one trick would be detecting when you go from processA() to processB() ... I'm assuming the array should be re-initialized at that point. Hopefully, there is some way of detecting within commonStuff() when the time has come to re-initialize. Alternately, you could provide a second closure method for re-initializing the closure, and invoke that at appropriate times from processA() / processB().

sub processA {
   ...
   commonInit()
   commonStuff( $various, $vars );
}
sub processB {
   ...
   commonInit()
   commonStuff( $various, $other, $vars );

}
{
    my @commonArray;

    sub commonInit {
        @commonArray = ();
    }

    sub commonStuff {
        # do stuff to @commonArray;
    }
}
[download]

This way, you can preserve your data without polluting the entire environment. You might also split the common stuff into several routines.

--
TTTATCGGTCGTTATATAGATGTTTGCA

Comment on Re: Design Question Select or Download Code

Replies are listed 'Best First'.
Re: Re: Design Question by Anonymous Monk on Aug 07, 2003 at 02:51 UTC
This was actually pretty quick to implement, so I've tested it out and it works great. I do need the array outside of common_stuff so I didn't use a closure. This approach seems to get exactly what I want without the necessity to clean-up a global. Are there any negatives with doing things this way that I should be aware of? The main problem I saw is that it required a change to the argument-lists for some functions.	[reply]
Re: Re: Re: Design Question by TomDLux (Vicar) on Aug 07, 2003 at 03:44 UTC
Beginner/Intermediate programmers are sometimes intimidated by an array reference or hash reference. The way I see it, they think ( or someone tells them ) that referenceces are complicated, so they get frightened and do things wrong. Since you know that references are actually quite easy, you should be fine. It takes a slight bit of effort to keep track of when a variable is actually a reference to a hash, so you can use it properly, especially when deealign with something several layers dow a data structure. But testing as you write code (Test:;Simple and test::More), and use of the Perl debugger and Data::Dumper when something doesn't seem right, will get you lots of working code in no time. -- `TTTATCGGTCGTTATATAGATGTTTGCA`	[reply]
Re: Re: Re: Re: Design Question by kral (Monk) on Aug 07, 2003 at 09:29 UTC
Beginner/Intermediate programmers are sometimes intimidated by an array reference or hash reference. The way I see it, they think ( or someone tells them ) that referenceces are complicated, so they get frightened and do things wrong. I agree with you. Maybe if perl newbies could see references as sort of pointers, they could found them easier to understand. ---------- kral (sorry for my english)	[reply]