Sam Vilain writes: > Eric Wilhelm wrote: > > > Just spent way too much time trying to find a bug when it turns out > > that I just had a full disk. So, food for thought for today: > > close() does not always return true. close(FILE) or die "file > > error: $!"; > > You don't already check the return value of every system call?
I don't. > Too tedious? That, and it makes the code look messier than needs be; a lexical variable going out of scope is very clean. > Just use IO::All. I've looked at IO::All a bit, but never actually tried it -- it looks sufficiently daunting that I've never put the effort in to learn it rather than using something I was already familiar with. Possibly, if it really is as easy to use as it claims, it just suffers from too much documentation. I'll consider it the next time I'm writing a script that does a lot of stuff with files, but if reading from one file once is the only IO a script does then this seems like a massive prerequiste to pull in: suddenly I've added a big prereq to a project, and confused other coders in the team who know Perl but don't know IO::All, just to write 2 lines of code instead of 3 -- that doesn't seem worth it. Normally I don't buy the "but I don't want to use a non-standard module cos that adds dependencies" argument, but in this case I think it makes a big difference. Some of the things Ingy's doing in IO::All do look to be more Perl-ish than the current built-in Perl ways of achieving them, and I think I read Larry saying he'll incorporate some of them in Perl 6, which would be mos welcome. Sam (or any other IO::All users reading this), what's your experience of IO::All? How much effort has it saved you? Does it make your code look too confusing for other coders (I'm thinking of the overloaded comparison operators being used for something other than comparison, for instance)? Have you ever found it to be 'too clever', automating something in an inappropriate way? And finally, an implementation question, which, while not strictly relevant to a user of IO::All, does seem on-topic for a module authors' mailing list: does the Spiffy thing make sense to you? (I get the feeling that there's something I'm missing, or that I'm not clever enough to understand it.) For comparision, I've recently started using Path::Class, which is an excellent module. This also adds a non-standard dependency to file-handling tasks that other coders on my team may not have met before, and it doesn't do anything that isn't possible with core modules. But it's sufficiently well focussed that I could grasp it in one go, and see clear benefits; it feels natural, with objects representing obvious things and having intuitive interfaces: my code is definitely cleaner for using it, and I'm not worried that my co-workers will have trouble with it. (Actually, possibly one of the reasons I'm liking using Path::Class is that while it theoretically is a better interface to using File::Spec, we weren't using File::Spec previously, but concatenating and interpolating strings, awkwardly and non-cross-platformily; so it's a definite improvement.) Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
