Let's try this again (I already replied to this once but lost it in
the aether somehow...)
The Ruby community has long held that names are important for methods
-- they should be descriptive and help the programmer. We've never done
a very good job with names for projects/libraries (at least in my opinion),
maybe it's time for us all to spend a little more time and effort in that
direction.
Are you suggesting that we should start moving in the Java direction
with regards to library naming? Perhaps your are right. Perhaps that
someone has now named a library "God" is a real omen. It's a tuffy
though. Creative names have been a hallmark of Ruby, with _why being
sort of the exemplar. I suspect, to move in the other direction would
require a real campaign on the part of the community, especially Matz,
the RubyGems teams, and the RubyForge guys.
The topic interests me a good bit because I have broken Facets down
into a bunch of little mini-projects. Any of which could easily be
packaged and distributed independently -- and I have flirted with
doing so. But it's problematic for a couple of reasons.
Firstly, there's nearly 100 of these mini-projects, and most have
fairly generic names. (I don't want to get too creative, or I won't be
able to find anything!) So If I released them as such I'd quickly soak
a bunch of Gem namespace. But maybe that doesn't matter? OTOH, if I
release in a more Java-fashion, say for example, 'facets-annotations'
instead of just 'annotations', then I feel like I'm hurting myself
from a marketing stand point. Someone else could just come along and
use the plain name for themself. So I don't feel like there's much of
an option. RubyGems is sort of pushing the use of creative names b/c
of this. That's why I've sometimes wished Gems has a project flag. If
two packages had the same name than you could select from them based
on their project. After all, that's how RubyForge is organized.
Secondly, (and maybe this a little OT but...) if I did release these
many mini-projects, I'd run into the issue of potential version
conflicts between them and the original all-in-one package, because
they contain the same libs. I'm not sure there's an easy way to
circumvent this issue should it arise. OTOH, If I instead made the all-
in-one project simply a multi-package, i.e. a package that has no libs
itself, just dependencies on the many mini-packages, then there's the
fact that RubyGems' require implementation is terribly inefficient.
Plus Gem's standard install procedure asks you to confirm every
dependency. Who wants to do that for 100 mini-libs? Blech! (Yes, I
know about -y, but no one expects they'd _have_ to use that for their
own sanity
T.