If you do end up deciding to go with this type of framework where you pass in code, please don't use string eval. That's yucky. You'd be better served with anonymous coderefs, along the lines of:
get_data(
pre => undef,
while => sub {
my $content = shift;
$content =~ tr/ / /s;
return $content;
},
post => sub {
my $instances = shift;
write_log("Found $count instances");
},
);
| [reply]
[d/l] |
To the OP, yes, it seems like you're starting down a reasonable road. Along that road is revdiablo's suggestion, which is a significant improvement, both in speed and maintainability (compile time errors can be caught easier).
To continue along this road (IMO), which is something I've done many times, I've started to take some serious advantage of $_. Rather than passing in a variable, just assign it to $_. Then your get_data call would look like:
get_data(
pre => undef,
while => sub { # 'handle' may be a better key, IMO
tr/ / /s;
},
post => sub {
write_log("Found $count instances");
},
);
As you can see, this can really trivialise the code. The cost (and there is always a cost, otherwise it wouldn't be called a 'trade-off' ;-}) is that you have to be extra careful to localise $_ appropriately. So you have to localise $_ in the get_data function, saving the original value, perhaps, if you'll still need it after the callback, and, should you need $_ again in the callback, localise it again there. However, 99.999% of the time, you won't need to do so in the callback, continuing to make this a pretty good tradeoff.
As a secondary change, I'd call this function "_get_data" instead as a signifier that this is an internal-to-your-module function and probably should not be called directly by anyone outside your function. However, I wouldn't go overboard and force it on anyone by, for example, making it a lexically scoped anonymous sub, such as:
my $_get_data = sub { ... };
But that's just me. | [reply]
[d/l]
[select] |
I like revdiablo's approach (++).
This could be taken one step furthur - Make an object class out of it.
What you are operating on looks like a File, so, the myFile package could hage a get_data method. You would create an instance of "myFile", provide it with a file name, filter conditions, pre and post processing anon subrefs, then simply call get_data on each instance of the myFile class.
"Man cannot live by bread alone...
He'd better have some goat cheese and wine to go with it!"
| [reply] |
I suggest reading Higher Order Perl, particularly the first chapter, which talks about callbacks. | [reply] |
Thanks itub! I plan to put the 30% off coupon from Borders to use :)
| [reply] |
It depends on what you are trying to do. Do get_states, get_ids, etc., operate on the same set of files in your program?
It may be better if you just have a single sub that returns an array (or reference to an array) of file attributes, or whatever form best suits your application needs, in a manar similar to the stat function.
This way, you keep all your code in one spot, plus you have the added benefit of doing only a single pass on the file, instead of each sub doing a separate pass on the same file.
You can also pass in an optional parameter, say, -want => [ qw/ id states / ], so that you can tell the sub that you only want a subset of file hashes, otherwise the sub will return the complete set of file hashes.
| [reply]
[d/l] |
Roger,
Each sub works with a unique file.
| [reply] |
Why eval, and not a code block (like what you'd use with sort, map, or grep)? | [reply] |