> I prefer Math::Calc::Units to Units::Calc. I also prefer Calc::Units to
> Units::Calc.
>
> The first question to ask is, what does this thing provide? It provides
> a calculator. Hence Calc. What sort of calculator? A units
> calculator. Hence Calc::Units. The primary thing it provides is a
> calculator, not a unit.
Hm. I guess I was looking at it another way. What distinguishes the
module? Units. What does it do with them? Calculates stuff. So if I were
looking for exactly this, I would first go straight to Units, rather than
crawling through Math::, Calc::, Eval::, Expr::, etc.
On the other hand, that's sort of backwards from a hierarchical
categorization point of view. The most general should come first. And my
argument above doesn't work very well in practice anyway -- when looking
for a certain bit of functionality, there's a good chance that the
functionality is provided in a module primarily focussed on something
else.
And I'd be doing 'i /Unit/' in any case.
> The issue of whether to put it under Math:: or whether to leave it at
> its own top level has to do with:
>
> - are deeply nested CPAN module names a good or useful thing?
> => *shrug* People seem to be OK with three-level names.
Two conflicting forces: (1) shorter names are easier to remember and
communicate verbally ("oh, just go grab object class methodmaker auto utf8
from cpan, it does just what you want" "uh... could you write that
down?"); and (2) too many top-level packages are annoying and defeat much
of the point of categorization.
Math::Calc::Units seems reasonable to me. I'll go with that unless
somebody objects before I release it. I would use Calc::Units if there
were already a Calc:: toplevel, but there isn't.
Thanks!
