On 06/10/2010 05:07 AM, Mark J. Reed wrote:
On Thursday, June 10, 2010, Leon Timmermans<faw...@gmail.com> wrote:
I agree it should be similar to normal FS interactoin to make matters
as intuitive as possible, but I horrified by the idea of overloading
open() that way
But open is already overloaded in p5, with pipes etc. We don't want
to repeat the mistakes of the past, and the fact that open(FH, $foo)
could run an arbitrary shell command was arguably a mistake, but
transparent access to storage where possible is the way to go.
We can provide a way to limit the behavior when you want - a pragma,
option to open(), or just sticking "file://" in front of a value to
force its interpretation as a plain pathname - but even then, who
knows what Fuse filesystem might be mounted and doing strange things
with your innocuous-looking file access? I'd rather have that
flexibility directly supported in the language.
Of course, different types of storage have different features; there's
no completely unified interface. But to the extent that a cloud disk
system or document database functions as a collection of data blobs
accessed by a pathlike key, enabling the standard filesystem access
pattern for it (in addition to whatever specific functionality it
needs) makes sense, IMHO.
Doesn't it make sense to just make it a method for the class/role?
my Amazon $fn .= open("$path-to-input-file-location/$file-name", :r) or
die $!;
--
Kevan Benson
A-1 Networks
