|
Re^2: Paul Graham on Great Hackers
by hardburn (Abbot) on Jul 29, 2004 at 18:00 UTC
|
A file handle is already an abstraction. Sure, it's usually attached to physical bits on a magnetic disk, but Unix is explicitly designed so that a "file handle" could also be many other things. It could be a pipe to another program. It could be a network socket.
The professor in question seems to have a problem making arguments. A file handle is in no way tied to magnetic-based storage, and hasn't been for 30+ years. If you want to say that a file handle is a poor abstraction, you must at least show a better one. I can see how "it's just a big string" could be handy in some places, but it would be no good in others.
For instance, on a networking socket, the "big string" would be constantly changing as data gets passed back and forth. You couldn't treat it as "big string" because a typical string isn't affected by external systems in typical operation. In other words, you can't completely abstract the underlieing operation. OTOH, the only difference (from my program's point of view) between a network handle and a file handle is how it's opened. After that, it's all the same operations.
----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.
| [reply] |
Re^2: Paul Graham on Great Hackers
by jdporter (Paladin) on Jul 29, 2004 at 16:59 UTC
|
that's exactly what Perl should do
should do?
That is absolutely absurd. You may as well say that an entire database (table space) should appear in perl as one big string. No? Then where do you draw the line?
It is possible (via modules such as Tie::File and Tie::MmapArray) to get behavior like what you're talking about; but it shouldn't be the only way to work with files. Sometimes a file is too large to load all at once. Sometimes a file is really a stream/pipe/socket. Sometimes a file is being written by another process at the same time. If you're a programmer, you need to know, and to handle these situations. Any proposal to require that files be abstracted as strings is naive at best.
| [reply] |
|
|
When i say one big string i mean that it would appear to be a scalar/string to the programmer, not that it is implemented as a big string. The same could indeed go for a socket for that matter.
edit: Not a database table, which has an inherent structure. Perhaps that'd be an array of arrays.
I'm talking only about the interface to the file/socket. You could concatenate something to a string which would write it to a socket.
| [reply] |
|
|
Why is that better? I think about the typical operations (methods) that are pertinent for strings, and I don't see how they fit on a database. So length gives me a count of the total bytes in the database. Why do I care? If I parse this database "string" on, say, ';', the chunks I get are meaningless. No, mapping a String abstraction onto a file or database is (in general, I'm saying) a complete failure.
| [reply]
[d/l]
[select] |
|
|
A hash of arrays would be more appropriate assuming you mean a typical RDBMS-ish system. There is no order to the rows in a table and you'd violate that by providing an array. Maybe if we had an array with no order then you could say that.
| [reply] |
|
|
Re^2: Paul Graham on Great Hackers
by Joost (Canon) on Jul 29, 2004 at 13:12 UTC
|
Do you mean totally abstract out the concept of a file handle, and only handle files as "big strings" (as was suggested on the perl6 language list recently), or do you mean just implementing a file-handle as a scalar? You can do that already since perl 5.6:
open my $fh,"< file";
while (<$fh>) {
# stuff
}
close $fh;
I agree that this should have been the default from the start, but the file-handle type is probably an artifact of staying compatible with perl 4 (which had no objects).
update: here's the discussion on perl6-language
| [reply]
[d/l] |
|
|
I really mean handle files as big strings. Performace wise, these could be made equivalent:
while (<FH>)
{
}
# or
while (split(/\n/, $file_scalar_thing)
{
}
And when $file_scalar_thing goes out of scope, it's saved (if changed). | [reply]
[d/l]
[select] |
|
|
I think the idea is fascinating, though I feel
for (split/\n/,$string) {
}
is not consice enough ;-). There's a whole thread about implementing this in perl 6 here. Incidentally, there's also talk about adding an encoding layer on strings, so you can handle strings as collections of bytes, unicode chars, uncode combined chars or lines (though the syntax escapes me at the moment)
| [reply]
[d/l] |
|
|
I don't know about you, but I sure don't want every file I open to have changes saved when it goes out of scope.
Believe nothing, no matter where you read it, or who said it - even if I have said it - unless it agrees with your own reason and your own common sense.
-- Buddha
| [reply] |
