Henrik Martensson wrote:
> Hi,
>
> I have a question about the best practise in naming Ruby modules.
>
> I am working on a module for unit testing XML documents (and document
> fragments). It would be logical, I think, to name the module
> Test::Unit::XML, and to load it using "require 'test/unit/xml'".
>
> However, this naming scheme could cause problems. For example, if the
> core unit test package is extended with assertions for testing XML.
> Also, even if my xml.rb file is physically separate from the files in
> the core test/unit directory, I don't feel comfortable with the
> possible overlap in names.
>
> I could of course change the names:
>
> XML::Test::Unit
> require 'xml/test/unit'
>
> or I could do something like this:
>
> Test::Unit::XML
> require 'testunitxml'
>
> However, I neither of these alternatives is as appealing.
>
> What is the recommended Ruby practise in these cases?
>
> I plan to release the module, whatever its name, on RubyForge as soon
> as the naming issue has been resolved.

Is this a general module for XML testing or is it a module for testing
specific XML?  In the former case I'd contact project maintainers of
Test::Unit and discuss with them whether and how to integrate your code
into Test::Unit.  In the latter case I would definitively avoid using
Test::Unit's namespace.  In that case you should use the namespace of your
project along the lines of YourProject::Test::Xml or
YourProject::Test::XML.

HTH

    robert