From: Dave Thomas <Dave@...>
Date: 2002-02-26T00:19:15+09:00
Subject: Re: [ANN] TestUnit 0.1.1

Tobias Reif <tobiasreif@pinkjuice.com> writes:

> Dave, it would be nice if you could explain what I'm missing.

OK

DT> A minor incompatibility: the original toplevel 'rubyunit' aliased the
DT> global constant
DT> 
DT> TestCase = RUNIT::TestCase

TR> That looks strange to me.

Perhaps, but its valid.

DT> so that all you had to write was
DT> 
DT> require 'rubyunit'
DT> 
DT> class TestFred < TestCase

TR> AFAICS, the same (not having to type RUNIT::) can be achieved by
TR> not including it in a module named RUNIT(?)

That isn't the point. It _is_ in a module already. The 'rubyunit'
extension hides that fact by aliasing a class name.


TR> I thought that I either
TR> a) don't use a module wrapper as namespace separator for a lib, then
TR> the user doesn't have to type MODULE_NAME:: ; but then there can be
TR> conflicts with other namespaces;

TR> or
TR> b) wrap the classes in a module to separate the namespace: then the
TR> user has the choice of

TR>    1) including the namespace and saving some keystrokes, which is
TR>       OK if there can't be a conflict because no other namspaces are
TR>        used,
TR>    or
TR>    2) dont' include the namespace, type the MODULE_NAME::s, and thus
TR>       avoid conflicts with other lib's namespaces.

TR> In your example, it looks to me as if the advantage of wrapping the
TR> lib in a module RUNIT is lost by the aliasing: there could be
TR> conflicts with other namespaces, but no namespace "prefix" can be used.

(c) wrapping all the code, but making a hole in the wrapper in one place
    to make it easier for folks using the code. Creating a module adds
    one constant to the global namespace (the module name). Aliasing
    something inside the module to something on the outside adds just
    one more.



Cheers


Dave