File handle behaviour within objects

I am writing a Perl prgram that makes use of objects. Within the _init
routine of my object I:

open FH, ">myfile.$name" or die(...); # I have a number of these E.g.
FHA, FHB...
FH->autoflush(1); # To ensure there's only command buffering.

Within the objects' methods I:

print FH "My Stuff\n";

When I've done with my object I call a method $objectname->tidyup();
that closes all my open file handles.

Within main I have a loop that instantiates a new object, does some
work via the methods and then tidies up the object before going round
the loop again.

Now the issue I have is this. The first time round the loop everything
I expect to get printed on the file handles ends up in the output
files. However on subsequent iterations of the loop (I.e. a new object
is instantiated) only the first line of output ends up in the various
files. So If I go round the loop 4 times I have the first set of
output files all present and correct; but the second, third and fourth
set of output files only have their first line.

I have been through the program using the debugger and the code to
print to these files is definitely being called. So what is happening
to the output from the 2nd, 3rd & 4th object? I suspect this may be
something to do with the same file handle names (FHA, FHB...) being
used for each new object; but I don't understand how that's causing it
to screw up.

Can anyone explain this to me?

david.hollingworth@motorola.com (David) writes:

> I am writing a Perl prgram that makes use of objects. Within the _init
> routine of my object I:
>
> open FH, ">myfile.$name" or die(...); # I have a number of these E.g.
> FHA, FHB...

> Within the objects' methods I:
>
> print FH "My Stuff\n";
>
> When I've done with my object I call a method $objectname->tidyup();
> that closes all my open file handles.

This is probably a bad design choice. Better to use lexically scoped
filehandles.

open $self->{FH}, ">myfile.$name" or die(...);

These will be implicitly closes when the object is destroyed. Also
multiple instances of the object won't clobber each others files.

[ snip English prose ]

> Can anyone explain this to me?

Please produce a minimal but complete Perl script to illustrate your problem.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

Brian McCauley <nobull@mail.com> wrote in message news:<u965bu2774.fsf@wcl-l.bham.ac.uk>...
>
> This is probably a bad design choice. Better to use lexically scoped
> filehandles.
>
> open $self->{FH}, ">myfile.$name" or die(...);
>
> These will be implicitly closes when the object is destroyed. Also
> multiple instances of the object won't clobber each others files.
>
> [ snip English prose ]
>
> > Can anyone explain this to me?
>
> Please produce a minimal but complete Perl script to illustrate your problem.

Thanks Brian, this is pretty much what I've ended up with. To produce
a minimal script that reproduces it will be difficult as it's part of
a complex set of classes involving parsing & processing some XML
documents. I'll see if I can reduce the whole thing to a bare mnimum.

File handle behaviour within objects - Perl

File handle behaviour within objects

LinkBack

Thread Tools

File handle behaviour within objects

Re: File handle behaviour within objects

Re: File handle behaviour within objects

Similar Threads

Clarifying creation/destruction of TreeVew.Handle and collapse behaviour

Contradictory behaviour of temporary objects

Graphics objects --- passing the object vs the handle

File Handle Reading Blues: Rereading a File Handle for Input

Re: Handle leak when creating COM objects from ASP?