Re: Pathname needs a makeover

--- Gavin Sinclair <[e-mail]> wrote:

> On Wednesday, December 8, 2004, 10:47:49 AM, Daniel
> wrote:
> 
> > 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.
> 
> I'm not suggesting that it _should_ be based on
> Array, but that
> actually makes about as much sense as String.  For
> example,
> Pathname#+.  A pathname is conceptually a list of
> entries in a
> hierarchy.

I think maybe we see a pathname as different things. 
To me, "a pathname is-a string" is true.  To you, it
seems, it isn't.  I suspect I see a pathname as a
whole that can be split into parts, while you see it
as parts that are combined into a whole.  Or
something.
 
> > 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.
> 
> Further, if it subclassed String, you have to
> explain to your users
> that #each and #+ don't work as they (probably)
> expect.  Unless you
> propose to change the meaning of Pathname#+, which
> would kind of
> undermine the whole class :)

Actually, I define #each in my example.  As for +, if
you know that Pathname is a subclass of String, and
you know how String#+ behaves, I'm not sure what the
surprise would be.  We could always redefine it to
match the current behavior, not that I totally
understand the source as it is now.
 
> >> > - 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?
> 
> They work fine, just like
> 
>   File.mtime?('/usr/bin/fahslkgjherlkshfekhflas')
> 
> works fine.  In fact,

s/may not work/raise an error.  Raises an ENOENT error
on my system.

<snip>
 
> I'm the opposite.  I really like the kitchen sink of
> methods in
> Pathname.  For example:
> 
>   path = Pathname.new('/tmp')
>   path += 'example-123'
>   unless path.exists?
>     path.open('w') do |file|
>       file.puts "What a nice OO interface!"
>     end
>   end
> 
> I know my feeling is not universal (PragDave
> expressed a certain
> ambivalence about it in Pickaxe II), but to me, this
> is the way file
> access _should_ be done in an OO language.  I cringe
> when I see code
> like
> 
>   File.open(File.join(File.basename(path),
> rel_path)) {...}
> 
> and unfortunately, I see code like that quite often.
>  Compare:
> 
>   path = Pathname.new(path).basename + relpath
>   path.open {...}

I agree it can be convenient.  It just feels like it
went overboard.

Well, anyway, it seems like there are some patches
that could be made to the current release if nothing
else.

Regards,

Dan




		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250