In article <8FE83020B9E1A248A182A9B0A7B76E73015E6BDC / itomae2km07.AD.QINTRA.COM>,
  "Berger, Daniel" <Daniel.Berger / qwest.com> writes:

> assert_equal('../../d',
> Pathname.new('a/b/../../../../c/../d').cleanpath.to_s)
>
> The current definition of cleanpath says, "Returns clean pathname of
> +self+ with consecutive slashes and useless dots removed.".  For the
> above test I would have expected "d" as the result.  In my
> implementation, that is what is returned.

The current pathname.rb returns '../../d' too, because the dots left
are not useless.

> The other difference is that my implementation removes trailing '/'
> characters and unnecessary '.' characters.  Here's a test from the
> current implementation:
>
> assert_equal('/a/.', Pathname.new('/a/.').cleanpath(true).to_s)
>
> My implementation simply returns "/a".

Pathname.new('/a/.').cleanpath returns /a too with the current
implementation.

cleanpath(true) consider symbolic links.  If /a is a symbolic link to
/b, lstat("/a/.") and lstat("/a") is different.  So cleanpath(true)
returns "/a/.".

> Yes, I merely removed the rdoc comments for the sake of brevity.  If you
> download the 'facade' package from the RAA you will see the comments in
> facade.rb.

I saw facade.rb.  It has a comment for Facade#facade.  But I couldn't
find for a way to document methods generated by facade.  How document
Pathname#atime, for example?

> Ok, I took Mark's suggestion (and changed the reliance on
> File::ALT_SEPARATOR) and changed that to:
>
> @win32 = PLATFORM.match("mswin32")
> path = path.tr("/",@sep) if @win32

It may be a portability problem between Unix and Windows.

Currentry Ruby fundamentally uses "/" on all platforms. [ruby-talk:52429]
So a script which uses "/" is portable on on all platforms.
(This is not perfect of course but I think this makes some scripts
more portable.)

Your pathname.rb is not usable for this kind of portable scripts
because it converts "/" to "\" on Windows.  So a portable script using
your pathname.rb needs to care "\".

> I have explicitly decreed that the behavior of '+' is different.  It's
> documented - people will just have to accept it.  Otherwise, we should
> never override any method in a subclass, because hey, people might not
> expect different behavior.

Some people expects inheritance should be used for subtype.  The
people don't accept it because it is misuse of inheritance.

I don't see advantages of inheritance from String.  Pathname can have
String like methods even if it is not inherit from String, if it is
useful for Pathname.
-- 
Tanaka Akira