From: Daniel Berger <djberg96@...>
Date: 2004-12-08T08:47:49+09:00
Subject: Re: Pathname needs a makeover

Hi,

--- Gavin Sinclair <gsinclair@soyabean.com.au> wrote:

> On Wednesday, December 8, 2004, 7:51:11 AM, Daniel
> wrote:
> 
> > Hi all,
> 
> > I've taken a look at the Pathname class.  In my
> humble opinion, it needs
> > a makeover.
> 
> > Here are a list of how I think it ought to behave:
> 
> > - A pathname is a string.  Therefore, it should be
> a subclass of String
> 
> I don't see a good reason for that.  You mention a
> practical reason
> below and a theoretical reason above.  Practical
> reasons don't sway
> me, because there are more practical solutions (like
> delegation).  And
> I disagree with the theoretical reason.  A pathname
> is a pathname, not
> a string.  It could just as well be implemented as
> an array.  Things like
> 
>   pathname[1..15]           and
>   pathname.center(30)
> 
> do not make sense when you consider what 'pathname'
> is supposed to be.
> I know we generally take a permissive approach with
> Ruby code, but I
> think we should look for the best design possible
> with stdlib classes,
> and a good design should clearly communicate the
> intention of the
> class.

Hm...to me a pathname is just a string that happens to
be in a specific format (i.e. it represents a
theoretical path on a file system).  I suppose you
could make Pathname a subclass of Array.  I'd be
interested to see an implementation of that, if even
for experimentation.

As for some methods not making sense for a pathname,
well, I'm not sure what to say to that other than it
might make sense for that particular user, knowing
that it was a subclass of String up front.  But, I see
your point.

> > - It should not implement methods that raise
> errors if the pathname does
> >   not exist.
> 
> Not sure what you mean here.

The various File and Dir class methods, such as
File.mtime, etc.  Isn't the presumption that our
pathname may our may not exist?  If so, why include
methods that may not work?
 
> > - Many methods are implemented manually that could
> be avoided by
> > subclassing the String class and mixing in the
> Enumerable module.
> 
> That's not a problem.  Delegation is a useful
> technique.  Any specific
> examples that bug you?

By subclassing String, we could eliminate the need for
==, <=>, to_s, inspect, and +.
 
> * (BTW String already includes Enumerable.)

Man, I totally forgot that.  Oops.
 
> * The following line looks flaky to me.  The
> condition should at least
>   be spelled out clearer.
> 
>     @sep = (File::ALT_SEPARATOR) && (@path =~ /\\/)
> ?
>       File::ALT_SEPARATOR : File::SEPARATOR

The @sep (separator) is assumed to be '/' *unless*
we're on Windows *and* the pathname includes a '\'
character.  Keep in mind that Ruby understands '/' on
Win32 as well, so that's why both conditions were
necessary.

If you have a better suggestion (that doesn't involve
resorting to a parser), I'm all ears. :)
 
> * #root could avoid calling #split twice

Only happens on Win32, where it needs to split out the
volume name.  Suggestions welcome. :)
 
> * You implementation is missing many methods from
> the existing
>   Pathname (like the Directory, IO, and Utility
> methods, as marked in
>   the documentation).  Is this intentional?

Yes (see my point above).

And now for the warm, fuzzy argument - as it stands
now the Pathname class feels like a kitchen soup of
methods - a bunch of stuff slapped together from other
classes, with a few methods of its own sprinkled in
for good measure.  It just feels clunky and haphazard.

But, if folks would prefer delegation to subclassing,
then I guess much of this is moot. :/

Regards,

Dan


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250