On Oct 11, 7:22 pm, Kevin Wright <[email protected]> wrote: > If there were two distinct classes for these two distinct ideas: FileRef and > Filesystem, then the problem would go away. > Methods like File.isDirectory() would become Filesystem.isDirectory(FileRef) > and methods like getCanonicalFile would simply be a mapping from one > (immutable) FileRef to another.
This would not change anything. The difficulty is not with the API in this case, though it could probably be better. The difficulty is with the fact that IO does not play nice with the functional concepts. IO is all about side-effects. Whether you use File or have FileRef and Filesystem is immaterial -- someone somewhere will have to take a file handle and so something with it. That's the whole point. We just have to deal with it. But it's not the end of the world. There's nothing stopping us from writing a nice high-level file/IO management library or framework. In some sense that's what RDBMS is for, but if we want something a little lighter, there are surely ways to go about that on top of standard file API. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
