Re: [ ruby-Patches-1939 ] Pathname, totally revamped

On 5/22/05, Daniel Berger <[e-mail]> wrote:
> --- daz <[e-mail]> wrote:
> >
> > ----- Original Message -----
> > From: Daniel Berger
> > >
> > > class Pathname < String
> > >
> > > [...]
> > >
> >
> > Related - [ruby-core:3919], short enough to quote in
> > full ...
> >
> >
> #---------------------------------------------------------------------------
> > #  In message "Re: Pathname needs a makeover"
> > #      on Wed, 8 Dec 2004 05:51:11 +0900, "Berger,
> > Daniel" writes:
> > #
> > #  |- A pathname is a string.  Therefore, it should
> > be a subclass of String
> > #
> > #  It's not.  Pathnames can be given to open() etc.
> > in place of strings,
> > #  that's true.  But no more relation between
> > strings and pathnames.
> > #
> > #         matz.
> > #
> >
> #---------------------------------------------------------------------------
> >
> > In the same thread, it seemed that Akira-san was
> > open to the
> > potential of a revamp but also provided examples for
> > why
> > Pathname is not a String - and other helpful info.
> 
> We'll have to agree to disagree.  The main concern
> that Tanaka and others made was that certain String
> methods weren't appropriate for a Pathname, or that
> "+" was broken.
> 
> First, "+" works as you would expect.
> Pathname.new("a") + Pathname.new("b") results in
> "a/b".
> 
> Second, just don't use the methods that don't make
> sense.  There are methods from Enumerable that don't
> make sense with String but that doesn't seem to have
> made the String class any worse for the wear.
> 
> The other main concern people had was that,
> previously, I had dropped the File, Dir and IO
> methods.  I've put those back in.
> 
> > ----- Original Message -----
> > From: Daniel Berger
> > > Nobu wrote:
> > >
> > > > >       path.tr!("/",@sep) if
> > File::ALT_SEPARATOR
> > > >
> > > > This changes the argument.
> > >
> > > Yes, I know.  That's intentional.
> > >
> >
> > It's "rude".
> > You have no idea what stupid arguments I want to
> > pass.  :-)
> >
> > ... __FILE__ ... Config::CONFIG['mandir'] ...
> >
> > UNIX_PATH_STRING = './aa/bb/cc'.freeze
> > dos_pathname = Pathname.new(UNIX_PATH_STRING)
> >
> > #  TMP:5:in `tr!': can't modify frozen string
> > (TypeError)
> >
> > I froze it because, _somehow_, it kept changing !
> 
> The problem is that the Win32API methods won't work
> with forward slashes in most cases.  If you can come
> up with a pure Ruby solution that will handle forward
> slashes, backslashes, or combinations of forward and
> backslashes, and still work properly with UNC paths
> (including root determination), by all means I'd like
> to see it.  Otherwise, it's a necessary evil on Win32.

I think the point that is being made here is that it modifies the
actual string sent to the function, which is bad behavior, since it
can cause all sorts of surprises:

path = Config::CONFIG['libdir']  #==>"/path/to/libdir"
pn = Pathname.new(path)
Config::CONFIG['libdir']         #==>"\path\to\libdir"

A better solution would be to change the tr line from
     path.tr!("/",@sep) if File::ALT_SEPARATOR
to
     path = path.tr("/",@sep) if File::ALT_SEPARATOR
which will leave the original string unmodified.

cheers,
Mark