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>
