Right now, the naming of packages is something of a free-for-all:
people add their packages where they feel appropriate in the Ruby
library namespace.

To a point, this is convenient for users. If I write a markup package,
users can do something like:

   require 'markup'

   m = Markup.new(..)

However, as the library grows, I'm wondering if this simplicity could
lead to problems as we get name clashes and general confusion: does
the Trace module show program execution or outline graphic elements?

The Perl solution is to have a module hierarchy. My markup program
might be in text/markup/simple.rb, and users would do something like

  require 'text/markup/simple'

  m = Text::Markup::Simple.new(...)

or

  require 'text/markup/simple'

  include Text::Markup

  m = Simple.new(...)


However, this solution has its own drawbacks. As a user, all these
long strings of names it pretty daunting. As a module writer, it's a
pain to refactor, and moving things around ends up affecting a lot of
source code.  Also, until Matz gets

  module Text::Markup

implemented, you end up with a fair amount of additional indentation
in deeply nested files

  module Text
    module Markup
     module OutputFormatter

       class ToHtml ....


So, what do folks think? Should we start implementing module
hierarchies, or is there a better way. Should RAA.succ enforce all
this?


Cheers


Dave