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