From: Robert Klemme <shortcutter@...>
Date: 2010-10-06T16:44:45+09:00
Subject: Re: The Third Ruby - Ever Comes Out at Night?

On Wed, Oct 6, 2010 at 8:29 AM, Mike Stephens <rubfor@recitel.net> wrote:

> An interesting feature of Ruby is that a module can contain a nested
> module (as indeed with classes, although we are not using classes if we
> do procedural). This suggests you could represent hierarchies of
> functions ( a key element of structured programming) in hierarchies of
> modules.

I think there are two structuring mechanisms that should probably be
used for different things:

1. caller callee relationships, i.e. one function / procedure calls
other functions / procedures.

2. parallel and nested namespaces

Mechanism 1 is used to break down complex tasks in simpler tasks.
Mechanism 2 is orthogonal to that and should be used to group
functions / procedures which belong in the same domain (whatever that
is in a specific case, it can be a library, an algorithm etc.).
Nesting additionally allows to group different groups together to make
it clear which groups belong together (e.g. for a large library
different functionality which is only used by the library internally
could go into nested namespaces, although publicly visible these are
probably only used from within the lib).  Another reason to use
nesting might be to group according to organizational hierarchies (as
is usually done with Java packages which often start with
"com.company").

Your statement sounds a bit like you wanted to use module nesting to
also model caller callee relationships.  IMHO that would be a waste
because the caller callee relationship is already modeled in code via
actual calls.

Cheers

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/