"Mr. Shawn H. Corey" <[EMAIL PROTECTED]> writes:
[...]
> Yes, Dumper() calls its first variable VAR1 (it calls its second VAR2,
> etc.). This tells more than you know. The line:
>
> 'file' => undef,
>
> means that somewhere in your code (or the class) that 'file' was
> actually assigned a value (the value being undef). If not, then 'file'
> would not appear in the dump.
>
> Try: grep -w file Database.pm
> If on MS DOS: perl -n -e "/\bfile\b/ && print" Database.pm
What I want here is to unwind the hash that is inside $self hoping to
then understand what is supposed to be happening and where stuff needs
to be to fill the hash. $file is one of them.
It appears from a grep -nw file lib/Database.pm that file is assinged
a value by one of those scary shift clauses where you can't tell what
in the heck is being shifted. I think it must be our friend $self
again. Thats part of what is so confusing here... things run in
circles making it difficult to see what is supposed to be happening.
46: $self->{file} = $args->{file};
48: $self->_read_file($self->{file});
** => 214: my $file = shift;
216: open FILE, $file or die ("Cannot read database $file: $!");
564: # locks the lockfile, reads the counter file, see update_counters() for
568: # lock the view file
650: # unlock the file
697: my $db = Database->new( { file => 'art/data/photo.lst' } );
712: file path and file name of the database file
765:back to disk. Make sure to call C<$db->unlock()> to unlock the file
afterwards.
769: $view = Database->read_counters( $file );
771:Reads in the list of 'views counters' from C<$file>, with locking and merges
841:Use a real database compared to a flat text file for performance reasons.
849:See the LICENSE file in the distributon for the exact license this work
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
