On Wed, 16 May 2001, Craig Moynes/Markham/IBM wrote:
> Some of you may remember hearing about the logfile pruning/archiving tool I
> was working on (with the date parsing from the record and second
> calculations etc).
>
> I am wondering about the 'perl way' or using variables. I have created a
> class for a generic 'logfile'. I then have a series of instance variables
> such as the name of the logfile, the record seperator regular expression, a
> series of date formatting values, etc.
>
> Now I have methods that I am calling such as:
> $self->read_log();
>
> I do this to access the instance variables. I don't mind this it keeps it
> nice and clean. However I start to get into cases like:
> $self->prune_log( $num_of_records );
>
> I may decide later on to put all the log manipulators in a seperate
> package, for re-usability in other programs. In that case I would have to
> change all the log manipulators to accepts parameters for each instance
> variable that is now used.
>
> So I guess all this boils down to is the following question:
>
> Is it acceptable practice to use instance methods that access instance
> variables (essentially global variables from a pure look of the code) or is
> it better to pass in a slew of variables to a function for
> ease-of-reusability later on, which in turn makes the code a little uglier
> (in my opinion).
How are you managing your instance data? For efficiency and managability,
your instance data should be kept in a has that you bless into your
object.
As for passing in variables, pass them in as a anonymous hashref:
$self->prune_log({numrecs=>$num_of_records, date=>$date});
This makes it very clear what you are doing and almost self-documenting.
There's a cool trick for creating accessor functions for instance
variables also, using the AUTOLAOD feature for Perl modules (assuming your
class is a blessed hash). Rather than reproduce it here, take a look at
the Camel book in the chapter on objects (Chapter 12 in the Third
Edition).
-- Brett
