* Jonathan Rockway [EMAIL PROTECTED] [2008-07-02 18:30]:
* On Tue, Jul 01 2008, Aristotle Pagaltzis wrote:
If I see a module called Exception::Easy in a list of modules,
I have *absolutely no idea* what it does. In contrast, if it
was Exception::Class::Functions, I could immediately guess
pretty well at what it does, even if I didn’t know exactly.
I take it the opposite way. Exception::Class::Functions makes
no sense to me. Class? Functions? What? In the end, I will have
to click through and read the docs. The name is meaningless and
hard to type.
Fair enough.
We can reasonably disagree on whether Exception::Class::Functions
is a good name. That’s neither here nor there. Personally I don’t
like it a lot, just better than the other options on the table so
far.
As for Exception::Easy, I think that makes a lot of sense. Oh
hey, a simplified interface for dealing with exceptions. I
will still have to click through and read the docs, though.
On this, I disagree.
Here’s litmus test: would you ever use the opposite adjective in
a description? If not, it’s not useful. I think you’ll agree that
no one would call a module Exception::Complicated except as a
joke. That means “easy” provides no useful differentiation in
practice.
In fact, the “simplified” in “simplified interface” is largely
redundant. Using an interface by definition means you are looking
for simplification in doing or accessing the thing that the
interface provides.
Similar words that say something without communicating anything
are “fast” and “flexible.” No one would say that they are trying
to achieve slowness or inflexibility.
In all of these cases, there is a tradeoff that you are accepting
to gain, say, simplicity at the cost of inflexibility, or maybe
flexibility at the cost of simplicity, or flexibility and
simplicity both at the cost of performance, or whatever the
particular tradeoff happens to be.
Additionally, Exception::Easy will only show up when searching
for exception, while Exception::Class::Functions will show up
when searching for class and function in addition to
exception. Exception is really the only relevant keyword, so
why contaminate the already-busy Class search with something
that's not relevant?
Because anyone who searches on “class” gets what they deserve.
:-)
In the end, I can't think of any module names that make sense
without knowing what they are. A few words aren't enough to
describe a module in detail. If you are faced with 10 search
results that sound relevant, you will just have to click
through and skim the docs. Even if the module does what you
want, the interface might not be what you want, or you might
dislike the implementation.
I see a trend here… you are the person who argued loudly that in
the end, anyone who wants to know how Catalyst works needs to
read the code, regardless of the state of the docs…
I think Shakespeare said it best:
What's in a name? that which we call a rose
By any other name would smell as sweet;
The converse is also true.
Whoohoo, let’s just call it NinjaCamp then (it produces functions
that throw fatal errors, geddit, geddit?). Naming is hard, let’s
go shopping. Maybe you want to (re-?)read Zen of Comprehensive
Archive Networks sometime.
Then again, you are the author of a Catalyst-based weblog app
called Angerwhale, which makes me wonder if you haven’t long
forfeited your right to take part in *any* discussion about
naming. :-P
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
