IO::File vs CORE::open

[EvanCarroll]

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

[ikegami]

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.

[chromatic]

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.

[Jenda]

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.

[chromatic]

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.

[karavelov]

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?