* 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/>
