I think a FileSystem class or module would be in order -- a system we could use in much the same manner as we use the command shell to access our filesystem.
fs = FileSystem.new
fs.cd('/')
entries = fs.ls
entries.each do |e|
if fs.directory?(e)
...
else
fs.open(e) { |f| ... }
end
end
It's not so common that we open files and harbor them, even less so for directories. So the FileSystem can have those defined within it as well, and there's no reason to even draw them up yourself. FileSystem can do it for you:
fs['afile.txt'] #=> <#FileSystem::File...>
fs['adir/'] #=> <#FileSystem::Dir...>
Clear, straightforward and convenient. But best of all, this single point of entry into all things "file system" may lead to more interesting possibilities, in some respect similar to what FUSE offers us in general, only confined to Ruby's realm.
I also wonder how remote file systems might fit into this... interesting considerations all.
2 comments:
I fully second your suggestion. Having used all the variuous modules you mentioned (File, FileUtils, etc...) in various occasions I foudnthem quite confusing and a bit of consisstency would be in order... May be in 1.9
Jonas: should the filesystem methods return open files instead? That sure wouldn't be pleasant. And if not, what class should these objects have, if not File? A separate class sure would confuse things even more.
Post a Comment