From: "Thomas R. Corbin" Date: 2001-12-06T02:04:47+09:00 Subject: [ruby-talk:27568] RE: Package Naming Mark Hahn wrote: > > I like java's dot-com convention. It absolutely guarantees no name > clashes. I like it too. sometimes it seems clumsy, but then any hierarchy can have it's disadvantages. > > -----Original Message----- > From: dave@thomases.com [mailto:dave@thomases.com]On Behalf Of Dave > Thomas > Sent: Tuesday, December 04, 2001 1:51 PM > To: ruby-talk ML > Subject: [ruby-talk:27485] Package Naming > > > > 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