Austin Hastings wrote:
--- Rod Adams <[EMAIL PROTECTED]> wrote:
I think part of the "mental jam" (at least with me), is that the read/write, exclusive, etc, are very critical to the act of opening
the file, not only an after the fact restriction on what I can do later.
But why? I'd argue that this ties in to the verbose/exception
discussion of a few weeks back: if the operation fails, let it pass an
exception up the chain that can be caught and resolved (once) at a high
level.
Guess I'm still in the
open "foo" or die;
mentality.
Given that file processing is so common in Perl, it deserves a high huffman scoring. The best way to do that is to abstract the operations away and replace them with a single declaration of intent. That declaration, of course, becomes a front-end for C or heavily optimized parrot.
In a heavily OO paradigm, there would be a swarm of subclasses of type
stream -- istream, ostream, iostream, exclusive_iostream, whatever.
Is
my $file = append_text_stream "foo.txt";
really so much better than
my $file = open ">>foo.txt";
I'd strongly prefer having a few, extremely flexible, orthoganal, and complete tools, that DWIM the common case for me, than to have to sort through a long list of classes to get what I'm looking for.
Now, there's nothing stopping open from returning an object of class FileHandle::OStream::Text::Exclusive or whatever. And that object can have lots of useful methods to play with. But let me describe to open what type of file I want, and let it sort it out.
Another part of me that resists this is that I don't necessarily agree with a heavy OO paradigm. I've written several large projects in both a OO environment, and non-OO. I have almost always found the OO paradigms force me to convert what I wanted to do into something much more painful than the non-OO methods. It typically breaks down into the moment you want to do something to an object that the class designer did not take into account, you basically have to either rebuild parts of the object heirarchy from scratch, or get into really ugly things like declaring everything a friend of each other, or having to many accessor method calls you can't help but slow the whole program down.
Also, my experience is that when following a heavy OO paradigm, you often fall into the trap of "There is only one way to do it. Why would you ever want another?"
Is all OO bad? of course not. I use for several things, on a frequent basis. Is something that's OO necessarily better than something that's not? Despite the rumors from the Java crowd, no.
So while I embrace Perl6 having extremely strong OO capabilities, I will argue strongly against it taking over the language.
It's often that I'll open a file to make sure I can save my results, then begin some process that is better measured in hours than seconds, and then begin outputting. It's not infrequent for me to have a list of five or six open statements at the start of a long process, and then close them all at the end.If I cannot open a file for writing (permissions, out of space, write locked, etc), I want to know the instant I attempt to open it
as such, _not_ when I later attempt to write to it. Having all these features available to open as arguements seems a much better idea to me. It's "Open a file with these specifications", not "Open
a file, and then apply these specifications to it".
But why? Do you really open files and then perform an hour of work before attempting to use them? I'll argue that's not the normal case; rather, the normal case is something like
open .... or die ... other_stuff() while (...) { print ... } close
and the intervening delay (other_stuff) is negligible in wall-clock
terms: when a failure occurs, the user hears about it immediately.
TMTOWTDI can apply here, I believe. You give me my way, I'll give you yours. Leave me open with all my parameters, and you can have your list of file abstraction classes. I could see having those classes part of core, if there's enough support for them, and then something simple like "use Files;" to turn them on.I do admit there is merit to your abstraction system, but IMO, it belongs in a library.I think rather that the abstraction should be the default, and the
individual "I don't trust Perl" functions should be available as
separate entry points if the user explicitly requires them.
Just my 2¢.
-- Rod
