--- Rod Adams <[EMAIL PROTECTED]> wrote:
> Dave Whipp wrote:
>
> >
> > Your case 2 is easy: "my Str $passwds is File("/etc/passwd") is
> > const". With that, we might even catch your error at compile
> > time.
> >
> >>/file/open/ and we're back where we started.
> >
> > Except that we've lost a layer of abstraction: the programmer
> > manipulates a file's contents, not its accessor. Text files
> > would be just an implementation of strings. No need to learn/use
> > a different set of operators. Want to read bytes: use $str.bytes. >
> Graphemes: $str.graphs. Also, we use the existing access control
> > mechanisms ("is rw", "is const", instead of inventing new ones to
> > pass to the C<open> function as named-args).
>
> 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.
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.
The suggestion is that we can derive an equally expressive vocabulary
using barewords and the occasional adverbial modifier.
> 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.
> 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.
=Austin
