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

On Sunday, May 22, 2005, 11:50:48 PM, Daniel wrote:

>> 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 [...]

I don't like Pathame inheriting String.  It just doesn't make sense to
me.  The String is merely an implementation detail for Pathname, not a
logical is-a relation.  Further, it's not even a very compelling
implementation detail - I happen to think of a path name as an array
of file/directory names.

At the end of the day, a Pathname is a Pathname and nothing but.  It
has a bunch of methods that are useful, just like any other object.  I
see no compelling reason for inheriting String (or Array), and see a
reason (compelling or otherwise) not to.

> 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.

That's not true.  Every method in Enumerable makes sense for String.
It couldn't be any other way: String implements #each, and all the
methods in Enumerable do something nice with #each.

Delegation is the right pattern for Pathname, not inheritance.  If
there are String methods that are useful in a Pathname, they can be
delegated easily.  (Same goes for Array, potentially.)

I like the fact that Pathname implements #to_str, but IIRC Tanaka
Akira thinks it's bad to rely on that.

Sometimes working with pathnames is more trouble than it should be.
In my ideal world the whole Pathname concept would be part of Ruby,
not part of the standard library.  The File methods are totally non-OO
and appear everywhere in people's code.  Pathname is so much more
elegant.

Gavin