[#5563] Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...>

Lately, I've been thinking about the future of ruby

44 messages 2005/08/19
[#5564] Re: Non-overridable and non-redefinable methods — Austin Ziegler <halostatue@...> 2005/08/19

On 8/19/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:

[#5571] Re: Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...> 2005/08/19

--- Austin Ziegler <halostatue@gmail.com> wrote:

[#5574] Re: Non-overridable and non-redefinable methods — TRANS <transfire@...> 2005/08/20

Just wanted to add a few things.

[#5581] Re: Non-overridable and non-redefinable methods — Austin Ziegler <halostatue@...> 2005/08/20

On 8/19/05, TRANS <transfire@gmail.com> wrote:

[#5583] Re: Non-overridable and non-redefinable methods — "David A. Black" <dblack@...> 2005/08/20

Hi --

[#5585] Re: Non-overridable and non-redefinable methods — Eric Mahurin <eric_mahurin@...> 2005/08/20

--- "David A. Black" <dblack@wobblini.net> wrote:

[#5609] Pathname#walk for traversing path nodes (patch) — ES <ruby-ml@...>

Here is a small addition to Pathname against 1.9, probably suited

20 messages 2005/08/22

Re: Pathname#walk for traversing path nodes (patch)

From: Paul van Tilburg <paul@...>
Date: 2005-08-24 17:08:44 UTC
List: ruby-core #5668
On Thu, Aug 25, 2005 at 01:00:24AM +0900, mathew wrote:
> ES wrote:
> >The absolute best name would be simply #each (incidentally, looks like
> >it would be available). That failing, #walk, #traverse or #each_node.
> 
> I'd like to suggest "descend", because it's really descending into the 
> path provided. The case where the path contains ".." is exceptional; I 
> imagine most real uses of the method won't be on ".." paths. And even 
> then, it's arguable that you're still descending into the *path*, it's 
> just that the path is relative and moves up the directory tree.

I seem to use it the other way around as well.  Paths are just a bit like 
Ruby's class hierarchy and when trying to walk up to find some related
files, I use something like this:

class Pathname

  # Calls the _block_ for every successive parent directory of the
  # directory path until the root (absolute path) or +.+ (relative path)
  # is reached.
  def each_ancestor(&block) # :yield: dir
    cur_dir = self

    until cur_dir.root? or cur_dir == Pathname.new(".")
      cur_dir = cur_dir.parent
      yield cur_dir
    end
  end

end # class Pathname

> The terminology then matches the common computer science terminology; 
> e.g. "depth-first recursive descent".

Maybe both ascend and descend are nice to have, although their niches
are probably different.

> I'm also curious to know what the real-world use case is for this 
> method. I can't recall ever having wanted to descend a single path 
> component-by-component.

I use the above method to find a file that includes a file for the given Pathname
object, for that I have to look in the current directory and up, and up,
and up...

Paul

-- 
Student @ Eindhoven                         | email: paul@luon.net
University of Technology, The Netherlands   | JID: paul@luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181

In This Thread