From: Michael Witrant <mike@...>
Date: 2001-10-29T05:08:23+09:00
Subject: [ruby-talk:23692] Re: Path class (was: Re: FileSpec vs Dir/File class methods)

On Sun, 28 Oct 2001 08:50:54 +0900, matz@ruby-lang.org (Yukihiro
Matsumoto) wrote:

> Hi,
> 
> In message "[ruby-talk:23640] Re: Path class (was: Re: FileSpec vs
Dir/File class methods)"
>     on 01/10/28, Michael Witrant <mike@lepton.fr> writes:
> 
> | * Some other methods:
> |   - #read()
> |       if a block is given: like #open(filename)
> |       else: return the content of the file
> |
> |   - #write(data = nil)
> |       if data is not nil: write data to file
> |       else: like #open(filename, 'w') (and a block must be given)
> 
> They are probably confusing.  I think it's better to separate
> open-like methods from read/write methods.
 
I'd like a way to write and read files on one line from a Path. And I
don't like the mode argument in #open.
Maybe should I create #open_for_reading and #open_for_writing in the
cases where you want the IO object, but I found it convinient to group
them with #read and #write methods.
If you give a block to these methods, you ask for an IO object inside
the block. Otherwise, the methods do everything by themself.

Actually, #open_for_xxing methods can exist even if I keep this
behavior. But they probably need a better name.
#open_read_only, #open_read_write, #open_append, ...?
#open_ro, #open_rw, #open_wo, #open_ao, ...?
Both?
Any idea?

> |- Should String#path be renamed String#to_path?
> 
> "path" sounds fine for me (if I need to add method to String).

David Alan Black proposed Path[str] to create a Path from a String. I
like this way better than String#path, and still shorter than Path.new.

> |- Should #join (and #/) remove duplicate slashes?
> |  ie: '/bar/'.path.join('foo') => '/bar//foo' or '/bar/foo'?
> |  File::join does not.
> 
> File::join does not do canonicalization.  File::extend_path does.

Yes, but removing duplicate delimiters is not canonicalization. I don't
expect paths to be canonicalized automatically, but being valid.
'/bar//foo' is probably valid most of the time, but I wonder whether
such a path could break something.

> |- Any other remark or suggestion?
> 
> If you provide Path#to_str, pathes can be used like strings.

Path inherits from String, so it is already the case.
But since I don't think anymore that a Path should have *all* the
properties of a String, I'll probably provide Path#to_str, and implement
some String's methods in the Path class.

But providing #to_str do not allow use everywhere a string is required.
Dir and File methods say: wrong argument type Path (expected String).
a_string.== does not return true if a_string equals Path#to_str. How
could I make it work? (except by redefining String#==)

Mike.