Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

IO::File vs CORE::open

by EvanCarroll (Chaplain)
on May 12, 2009 at 18:53 UTC ( #763565=perlmeditation: print w/replies, xml ) Need Help??

A dispute, and finally a ban on irc.freenode.net/#perl, led me to investigate the differences between CORE::open and IO::File. The claim: both return the same thing. I was arguing to never use CORE::open, per the docs, experience, and for added clarity. In my eyes IO::File is more easily extended, and transparent in its operations.

Here is some of the conversation, I got a kickban, so I lost chanlogs. Lets try to clear it up.

11:43 <mauke> CORE::open is an interface to IO::Handle 11:43 <mauke> also, IO::Handle is from 5.003; three-arg open is from 5 +.6 11:44 <mauke> clearly open is more modern

It certainly isn't an interface *to* IO::Handle, at best it has some similarities to the interface *of* IO::Handle. Here is what the docs say on this. Now, that I read them, I can see how it is confusing.

File handles are now stored internally as type IO::Handle. The FileHandle module is still supported for backwards compatibility, but it is now merely a front end to the IO::* modules -- specifically, IO::Handle, IO::Seekable, and IO::File. We suggest, but do not require, that you use the IO::* modules in new code.
IO::Handle also touches on the fundamental differences between CORE::open's hack and itself.
Due to backwards compatibility, all filehandles resemble objects of class IO::Handle, or actually classes derived from that class. They actually aren't. Which means you can't derive your own class from IO::Handle and inherit those methods.
So I wrote a test on the two. For these tests, oofh is the filehandle opened with IO::File, while fh is the CORE::open version. Lets get some data! Comments added later.
## Two different reference types ok 2 - oofh is a reference ## though to an object. ok 3 - fh is a reference ## base type glob not ok 4 - they are the same reference ok 5 - oofh can call new() ok 6 - fh can call new() ok 7 - oofh can call new()->new() ## joy continues not ok 8 - fh can call new()->new() ## joy stops ## Both can do these, confusing isn't it... ok 9 - oofh autoflushed ok 10 - fh autoflushed ## But only one ->can('autoflush'), eh perl API I miss you. ok 11 - oofh can autoflush not ok 12 - fh can autoflush ## Only one is a true "object" ok 13 - oofh is an object per S:U:blessed() not ok 14 - fh is an object per S:U:blessed() ## But both are true filehandles ok 15 - oofh is an filehandle per S:U:openhandle() ok 16 - fh is an filehandle per S:U:openhandle() ## Revist test number #6 but with the byproduct of using IO::File to b +egin with. ## This one is amusing. not ok 17 - fh can call new wo/ IO::Handle loaded
I feel as strongly as ever, even though I didn't know fh's with CORE::open could $fh->autoflush, that all FH should utilize IO::File, and not CORE::open. The cause of this dispute was wanting to revise docs for novices. I argue for ignoring CORE::open. People shouldn't learn it first, if ever, in my eyes. If you want to revise the learning curve of perl, it is better to leave it out. The syntax is also scary for a lot of people. Who passes in a reference to a localized variable in a function anyway? If I wrote something that permitted silent failures and had a subroutine definition of.
sub _give_me_a_variable_to_hack_by_reference( my $foo );
Most programmers, perl and otherwise, would rightfully wtf me to oblivion. Also, what gives with a method call to a non-blessed-object, is there anything else in perl that breaks the API in such an unintuitive way? Oh you can find the test at http://gist.github.com/110655


Evan Carroll
www.EvanCarroll.com

Replies are listed 'Best First'.
Re: IO::File vs CORE::open
by ikegami (Patriarch) on May 12, 2009 at 19:23 UTC

    It certainly isn't an interface *to* IO::Handle,

    You can use it to calls methods in IO::Handle, so yeah, it is.

    <mauke> CORE::open is an interface to IO::Handle // also, IO::Handle is from 5.003; three-arg open is from 5.6 // clearly open is more modern

    Older = worse? nah, bad argument. The older module could be worse, but it's not because it's older.

    It's not like it's not maintained either. IO::File uses 3-arg open when possible.

    [Quoting IO::Handle,] Which means you can't derive your own class from IO::Handle and inherit those methods.

    That makes no sense. That's exactly what IO::File does.

    ok 3 - fh is a reference ## base type glob

    open's file handle *can* be a reference to a glob, but it can also be a glob.

    The glob can be magical (including tied) or not.

    The reference can be unblessed or blessed to any package.

    I feel as strongly as ever [...] that all FH should utilize IO::File

    I don't see where you explain why. What are the advantages of

    my $fh = IO::File->new($qfn, 'r') or die("Can't open file \"$qfn\": $!\n");
    over
    open(my $fh, '<', $qfn) or die("Can't open file \"$qfn\": $!\n");

    I have to load a module, create an object and learn a new permission notation just to end up calling open like I would anyway.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: IO::File vs CORE::open
by chromatic (Archbishop) on May 13, 2009 at 07:42 UTC
    If you want to revise the learning curve of perl, it is better to leave it out.

    Explaining OO before demonstrating how to perform file operations is definitely a revision of Perl's learning curve, but I'm not sure it's a revision of Perl's learning curve in the "easier to learn" direction.

    If you want conceptual purity of a single programming paradigm, you don't want Perl.

      Depends on the direction you are coming from. If you're used to the results of the "Everything is an object" mantra, the IO::File will look more familiar. I'd rather have "similar things should look similar, different things look different" than "everything looks the same", though.

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.

        If you're used to the results of the "Everything is an object" mantra, the IO::File will look more familiar.

        Yet how inconsistent with the rest of the core language.

Re: IO::File vs CORE::open
by karavelov (Monk) on May 13, 2009 at 02:22 UTC

    The build-in "open" function has a tons of functionality that could not be replicated using IO::File. Opening file-system files is just one of the cases that CORE::open covers. There are a lot of other cases as: dup-ing a fh, opening fh to memory location, fork-ing a child and splicing it's STDOUT to opened fh (pipes) etc.

    In short, with just one function with its little idiosyncratic language for open modes you could do almost all the things you could do with all IO::* modules (except sockets). You could hate it but there are people that like it, for various reasons.

    I do not fully understand your proposition for stop using CORE::open and start using IO::File. But why not use instead IO::Pipe? Or IO::String?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://763565]
Approved by Burak
Front-paged by Burak
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2022-05-20 22:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (76 votes). Check out past polls.

    Notices?