On 5/20/07, Joel VanderWerf <vjoel / path.berkeley.edu> wrote:
> TRANS wrote:
> > I would like to suggest that Pathname#ascend  and Pathname#descend
> > have an inclusion-flag parameter added to them to specify if the given
> > path should be included in the iteration or not. The default could be
> > true for backward compatibility. Eg.
> >
> > Pathname.new('/path/to/some/file.rb').ascend {|v| p v}
> >    #<Pathname:/path/to/some/file.rb>
> >    #<Pathname:/path/to/some>
> >    #<Pathname:/path/to>
> >    #<Pathname:/path>
> >    #<Pathname:/>
> >
> > Pathname.new('/path/to/some/file.rb').ascend(false) {|v| p v}
> >    #<Pathname:/path/to/some>
> >    #<Pathname:/path/to>
> >    #<Pathname:/path>
> >    #<Pathname:/>
>
> The following gives the same output:
>
> path = Pathname.new('/path/to/some/file.rb')
> path.parent.ascend {|v| p v}

Good point.

> Is it better in some cases to control this behavior by argument passing
> rather than by calling an extra method?

In can avoid an if condition:

  path.ascend(condition) {|v| p v}

vs.

  condition ?  path.ascend {|v| p v} : path.parent.ascend {|v| p v}

Though a variable condition is probably pretty rare, so maybe yours is
the better suggestion.

However I've made the same extensions to String (ie. String#ascend)
for use with File.join. In this case, we can't use #parent, so the
parameter becomes much more important. Unless there's going to be some
big push for the use of Pathname over File.join (which I would happily
support btw) then I think it would be nice to have corresponding
parameters for Pathname's methods.

T.