From: Sean O'Dell <sean@...>
Date: 2002-03-14T05:23:41+09:00
Subject: Re: Some potential RCRs

"Massimiliano Mirra" <list@chromatic-harp.com> wrote in message
news:20020313123710.C674@prism.localnet...
> On Wed, Mar 13, 2002 at 01:39:23PM +0900, Sean O'Dell wrote:
> > time and size.  By simply showing this information for each directory
entry,
> > you can display that information for the current directory and the
parent
> > directory without having to do anything particularly special.  Also, if
you
> > attempt to chdir a directory the user selects (in other words,
navigate),
> > and the user selects '..', they can get to the parent directory.
>
> Good points.
>
> > '.' and '..' aren't just artifacts.  If the user has selected a
directory,
> > it's easier and more efficient to get your stat information from '.'
than
> > from Dir.cwd(), and it's easier to change to the parent directory by
> > performing a chdir('..') than to grab the current working dir and parse
it
> > to find the parent to chdir to it.
>
> Easier than all would be a call to a Dir.chparent.  What I'm concerned
> about is, is Dir.chdir('..') going to work on Windows, Mac OS X and
> all the platform Ruby runs on?  If we want to write easily portable
> code, we write File.rename(..., ...) instead of `mv ... ...`, so there
> could be a portable way of going up a directory, exactly for the
> reason that you'd have to parse the current directory otherwise.
>
> This is similar to the GUI discussions: maybe not all toolkits have an
> OpenGL widget (as not all file systems support permissions), but all
> toolkits have button widgets (as all file systems support directory
> trees and parent directories), we just need to come up with an unified
> API that does the latter and hides the system-specific details.
>
> All in all I still feel that the file management routines work too
> low-level and shell-like and that we would benefit from some serious
> abstractions.  This is the direction I'm thinking in:
>
>
> joe_dir = Dir.new('/home/joe')
>
> other_dir = joe_dir.parent
>
> p other_dir.name                 # "home"
> p other_dir.path                 # "/home"
>
> joe_dir.entries.each do |entry|
>   if entry.directory?
>     print "dir:  "
>   else
>     print "file: "
>   end
>
>   print "filename: #{entry.name} (full path: #{entry.path})"
> end
>
>
> Dir#entries would not return an array of strings but an array of
> objects, which you could query for information such as name, path,
> date, permissions etc. in a much more Ruby-oriented way than with
> File#method(filename).

I don't agree with the abstraction concept.  Mac doesn't even have paths (it
tries to have them, but things aren't tied together using paths, so you run
into a lot of problems with them), so if Ruby is going to virtualize a file
system, it *still* couldn't do anything at all for the 2nd most popular
desktop operating system in the world.

Ruby isn't going to be the glue that binds all the world's file systems
together, so let's not whack off features from one file system just because
they don't exist in others.  '.' and '..' are near-universal for a reason.

Ruby isn't a virtual machine and I'm really not interested in a language
that tries to bundle every operating system feature into one plain vanilla
wrapper.  If I was, I'd probably use Java or something that is more
developed in that regard.  I'm using Ruby as a C++ programmer who is getting
off of Perl.  For me, Ruby needs to be the next logical step up from Perl,
not a tour through the twilight zone.

    Sean