Re: Pathname needs a makeover

In article <[e-mail]>,
  "Berger, Daniel" <[e-mail]> writes:

> I've taken a look at the Pathname class.  In my humble opinion, it needs
> a makeover.

First of all, Python people discuss various points for a class for pathname.
http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html

It may be interesting because some points you mention is disscussed.

> Here are a list of how I think it ought to behave:
>
> - A pathname is a string.  Therefore, it should be a subclass of String

No.  Various string operations are not suitable for pathname.

For example, Pathname.new("a") + Pathname.new("b") is Pathname.new("a/b"),
not Pathname.new("ab").

Also I want to distinct a pathname and a content of file.
For example, my library for HTML, HTree, has HTree.new(arg) method.
If arg is a string, arg is treated as HTML content.  If arg is a pathname,
arg is opened and its content is parsed.

> - It should be possible to break a pathname down into component parts
> and
>   iterate over them.  Therefore, it should mixin Enumerable.

I'm not sure it's useful enough.

> - It should not implement methods that raise errors if the pathname does
>   not exist.

pathname.open and pathname.read is required for polymorphic to URI.

If pathname and open-uri is in effect, uri.read and pathname.read can
be used polymorphically.

Although currently there are only two polymorphic methods,  I want to
implement other methods such as mkdir, etc.
(But writing methods needs authentication which needs security
consideration.)

This is my VFS plan.  So I don't want to remove filesystem accessing
methods which may cause an error from pathname.rb.

> - It should work for both Unix and Win32 style pathnames.

Win32 is not supported now because no one contributed.

> - It should make private methods private.

Acceptable.  List of methods?

> - The to_a method does not return something useful.

Implementing Pathname#to_a is acceptable.
-- 
Tanaka Akira