in reply to Re^9: Should Modules Do I/O?
in thread Should Modules Do I/O?

Who said anything about the user? What about the programmer? And who said that typing "tar xf $tarball $filename" at the shell prompt isn't shell scripting (and thus code)?

I think we're simply going to have to agree to disagree on your statement that "the very last place you want the results is in a file in the filesystem." That simply has not been my experience in coding with perl - it is very rare that I want my results anywhere but the filesystem. The rare time that I have used the filehandle form of File::Copy, for example, has been to concatenate multiple files (specifically, pksfx.exe and a zip file). Well over 95% of my calls to File::Copy are "copy($srcfile, $dstfile)". Which, in a perl script, is way simpler than "if ($^O =~ /win/i) { system "copy $srcfile $dstfile" } else { system "cp", $srcfile, $dstfile }" (all my scripts have to run on Windows, various flavours of unix and various flavours of Linux) or even way simpler than "open my $srch, '<', $srcfile or die $!; open my $dsth, '>', $srcfile or die $!; copy($srch, $dsth);" which is at least still portable (to more than just windows and unix).

Similarly, 100% of my usage of Archive::Tar has been to extract files to the file system, or to insert files from the file system. That's not to say 100% of all usage of Archive::Tar is this, only 100% of my usage. And the reason I chose perl wasn't to do post-processing of files, but post-processing of the archive: querying the archive to see what the root directory name was. Doing this is shell is possible, but quite ugly. Doing this in perl was easy. The commandline interface to tar simply doesn't have the option to look at files in an archive like this (specifically, I only look at the first file since I know that they will all have the same top-level directory). And then I just told Archive::Tar to extract normally, and could do something with that directory that was just created (i.e., create a symlink of "latest" to it). Filehandles and looping through all the files would have been a waste of my programming time since so many people do that - it's better situated in the module. If I had to do that, then I would have done this in shell script - it would have been a bit slower, but I would have spent less time programming it, which is always a consideration.

In fact, in all that I've done, I have very very rarely wanted a filehandle that wasn't going directly from or to a filesystem... and I used IO::Open3 for that. I am quite thankful that these module writers don't take the mathematician's view that the solution I want can be "trivially derived" from a single, flexible interface, but the engineer's view that "here's the derivation - just use it, and don't reinvent the wheel".

Replies are listed 'Best First'.
Re^11: Should Modules Do I/O?
by BrowserUk (Patriarch) on Mar 19, 2005 at 14:53 UTC

    In this context, "user", refers to the user of the API. Ie. The programmer who's code calls the API, as opposed to the programmer who codes the API. Perhaps you will re-read the post in that light?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco.
    Rule 1 has a caveat! -- Who broke the cabal?
[reply]
[d/l]

      Actually, I must be missing the distinction. You're saying that the programmer would use the command line invocation ... programmatically? Something like... 

        system("archive_tar.pl --tar $tarball --destination_path $some_path"
+);

      [download]
      instead of... 
        $tar->extract($some_path);

      [download]
      ? I'm not sure I see how this is a clear winner.

[reply]
[d/l]
[select]

        Now we are getting silly, but ... I'll play :)

        That would be more like: 

        system( "tar -xvf $tarball $some_path" ) == 0
   or die "tar failed: $?";

        [download]

        versus 

        use Archive::Tar;
my $tar = Archive::Tar->new( $tarball )
    or die "Failed to open $tarball : $!";
$tar->extract( $some_path )
    or die "Failed to extract $some_path: $!";

        [download]
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco.
        Rule 1 has a caveat! -- Who broke the cabal?
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom