in reply to Comparing references to sub's

The uncompressed ones I can open with just 
open(HANDLE, $filename) or die ...

[download]
and the compressed ones with 
open(HANDLE, "$unzip $unzip_opts $filename |") or die ...

[download]
These two different ways of opening a file are in two different sub's...

I don't see why you need (or want) two separate subroutines for opening the file -- the only thing different is the string being passed to open().

So, based on what gets returned by your "_detect_type()" method, why not just set a scalar to either $filename or "$unzip $unzip_opts $filename |" and pass that scalar to "open()". No need to keep track of alternate sub references (unless you have something else going on in those two different open subs that you haven't told us about...)

Granted, opening a pipe will return a pid, which you might want, but that can still be accommodated without needing a separate sub for a pipe open vs. a file open.

Replies are listed 'Best First'.
Re: Re: Comparing references to sub's
by leriksen (Curate) on Mar 20, 2003 at 03:36 UTC
    true - but the 'real' _open_<type> sub's actually do a lot of other verification and initialisation as well, so that the rest of the code can do its work with the lines from the file. That work is fairly specific to the type of the file - certain types of file are compressed and others are plain - so the verifying and init are specific to the kind of open we do. Thats why I broke them apart into two subs - to keep the type specific code localised. I just didn't show those bits as they weren't specific to the concept I was querying.
[reply]
      This makes sense if you're dealing with some form of compression other than "gzip", or if your dealing with multiple types of compression (i.e. part of the process is to verify what sort of "$unzip" and "$unzip_opts" are needed).

      If you were just dealing with a distinction between plain files and gzipped files, then you would want to use the Compress::Zlib module, or better yet, the PerlIO::gzip "layer" in Perl 5.8 -- this could simplify things a lot, to the point where you might not need separate subs for opening files and doing line-oriented IO (check this little node for a quickie sample of PerlIO::gzip in 5.8)

      UPDATE: (2010-10-18) It seems that PerlIO::gzip should be viewed as superseded by PerlIO::via:gzip. (see PerlIO::gzip or PerlIO::via::gzip).

[reply]
        Firstly, ++graff,

        Working in the same company as leriksen, I am sad to report that we are still using Perl 5.005.03 for production purposes. Perl 5.6.1 is available for development testing, but everything must work under 5.005.03 for the production environment. As such, the nice features of the PerlIO abstraction layer are completely unavailable to us at this stage. Momentum however is building, with more than just a little encouragement from those of us who work with Perl on a daily basis, for the development and implementation of a migration strategy to Perl 5.8.0 for both the development and production environments.

        All of that having been said, the code which leriksen is working on and writing test cases for is much more complex than differences in open arguments. While from a fundamental level, all code can reduced to the most basic of core functions with high levels of reuse within similar tasks. This however, is not the way in which I see most code being developed - Programming is to a large extent about abstraction and provision of high-level interfaces to functional constructs. It is based upon this philosophy of abstraction and with concern for future maintenance that leriksen has separated code and functionality.

         

        perl -le 'print+unpack("N",pack("B32","00000000000000000000001000111111"))'

[reply]
        This makes sense if you're dealing with some form of compression other than "gzip"

        I think he is. The way I read his post, it seems he's using Zip compression (i.e., PKWare format). There is of course also a module on CPAN for that (Archive::Zip), but if portability is superfluous the pipe he's using is more efficient in terms of programmer time. (If portability were desired, the CPAN module would be vastly preferable, however. Otherwise you have to worry about the syntax differences between pkzip, pkzipc, info-zip, and whatever else, and which one is installed, and... the module is going to make porting easier.) 

        for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc'
.'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$
p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom