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.


Mark J. Reed <markjr...@gmail.com>

Reply via email to