It might work better to have a "stack" of iterators, but the more I think about this, the more I think that your original API with a single iterator inside the object and the option to retrieve an explicit list of files in a category will probably be better for long-term maintenance.
DOH! Better still, make iterators a separate class File::Collector::Iterator with AUTOLOAD providing both get_TYPE_files and scan_TYPE_files methods, with the latter returning an iterator object. This allows moving the _selected_file instance variable into that iterator instead of making it part of the collection, which does not really make logical sense.
Here is a rough draft: (in File::Collector)
sub AUTOLOAD {
our $AUTOLOAD;
my $s = shift;
$AUTOLOAD =~ /.*::(get|scan)(_\w+)_files*$/ or
croak "No such method: $AUTOLOAD";
my ($mode, $type) = ($1, $2);
# Get the files and return appropriate file(s) based on method calle
+d
return @{$s->{$type.'_files'}} if ($mode eq 'get');
return new ref($s).'::Iterator' (@{$s->{$type.'_files'}}) if ($mode
+eq 'scan');
}
(in File::Collector::Iterator)
sub new {
my $class = shift;
bless [@_], $class;
}
sub next_file {
my $self = shift;
shift @$self;
return $self->[0];
}
sub selected_file { (shift)->[0] }
This is a low-overhead proof-of-concept that simply uses an array as the iterator and uses the first element of the array as the "selected file" variable.
This would require classes that build on File::Collector to also supply subclasses for File::Collector::Iterator, but that is probably exactly what you want: delete_file could be a method on the ::Iterator for the subclass that produces the "bad header files" category.
What do you think? |