Re: Module naming issues

My first impression, sorry, is that "Forest" is trying to be too cute. Who's going to search for a "Forest" module when they're looking for a tree data structure? And when I see "Forest::Tree", I think of forestry and the environment, not data structures. "Forest" winds up just being a vanity/brand, and doesn't convey anything about what the distribution does. The fact that you're thinking about aliasing is a sign that it's flawed in the first place. (And I know how you probably feel -- development names are tough to let go, it's easy to get attached to them through repeated exposure.)

Personally, I liked the name "Tree::Simple" -- it immediately stood out among all the tree modules. I'd prefer if you found something along those lines that conveyed what it does (i.e. the Noun::Adjective/Adverb style).

Tree::Persistant? Tree::Builder? Tree::Easy? Tree::Simpler? (The latter even conveys the connection to Tree::Simple but with the improved API and transparent persistance.)

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on Re: Module naming issues

Replies are listed 'Best First'.
Re^2: Module naming issues by stvn (Monsignor) on Oct 20, 2005 at 14:41 UTC
My first impression, sorry, is that "Forest" is trying to be too cute. Well, it is actually trying to be "more general", but it is kind of cute too :) Our module is not just tree data structures, but a framework for working with all different kinds of trees, including event handling and (for the most part) transparent persistence. So in a way it is a kind of digital forestry if you will, hence the name ;) Who's going to search for a "Forest" module when they're looking for a tree data structure? And when I see "Forest::Tree", I think of forestry and the environment, not data structures. A search for Tree will surely turn up Forest::Tree, but a search for "Tree Persistence" will likely bring up Forest::Tree::Persistence. This, along with some well written descriptions should give us sufficient enough rankings. But regardless of all this, I think it is wrong to cater to the current less-than-perfect/accurate search(.cpan.org) mechanism, and not assume that it will eventually improve. The idea behind the name, and the reason we are choosing to create a top-level namespace is that this module is not really a module, so much as it is a framework. A framework cannot be easily boxed into a generic TLN like Tree:: or Data:: or some other such thing. It makes sense to have a more original namespace, and (to take a que from ingy) it doesn't hurt to be cute or witty either, as people will remember it. The fact that you're thinking about aliasing is a sign that it's flawed in the first place. I disagree with this very much. Packaging a set of components together under a well organized namespace is (IMO) the Right Thing to Do. However, sometimes in order to do this right, you end up with long drawn out names which are a pain to type. Aliasing allows the user of your module to shorten the names to a more managable size, and at the same time allows the maintainer to keep their module namespace neat and tidy. (And I know how you probably feel -- development names are tough to let go, it's easy to get attached to them through repeated exposure.) Actually, we are not that tied to it yet. We are building this in anticipation of a particular $work project, so it is still a fairly localized change if we have to make it. Personally, I liked the name "Tree::Simple" -- it immediately stood out among all the tree modules Thanks, I really wanted to call it plain old "Tree" (which is what it was when it was only used internally at $work). My biggest problem with the name Tree::Simple is that when I first wrote it,.. it was fairly "Simple". It has now grown into much more (Tree::Simple::VisitorFactory, Tree::Simple::Manager, Tree::Simple::View, etc.) and so the name doesn't fit so well anymore. This is part of the reason why we are leaning towards a name like Forest. It has lots of room to grow ;) -stvn	[reply]

Replies are listed 'Best First'.

Re^2: Module naming issues
by stvn (Monsignor) on Oct 20, 2005 at 14:41 UTC

My first impression, sorry, is that "Forest" is trying to be too cute.

Well, it is actually trying to be "more general", but it is kind of cute too :) Our module is not just tree data structures, but a framework for working with all different kinds of trees, including event handling and (for the most part) transparent persistence. So in a way it is a kind of digital forestry if you will, hence the name ;)

Who's going to search for a "Forest" module when they're looking for a tree data structure? And when I see "Forest::Tree", I think of forestry and the environment, not data structures.

A search for Tree will surely turn up Forest::Tree, but a search for "Tree Persistence" will likely bring up Forest::Tree::Persistence. This, along with some well written descriptions should give us sufficient enough rankings. But regardless of all this, I think it is wrong to cater to the current less-than-perfect/accurate search(.cpan.org) mechanism, and not assume that it will eventually improve.

The idea behind the name, and the reason we are choosing to create a top-level namespace is that this module is not really a module, so much as it is a framework. A framework cannot be easily boxed into a generic TLN like Tree:: or Data:: or some other such thing. It makes sense to have a more original namespace, and (to take a que from ingy) it doesn't hurt to be cute or witty either, as people will remember it.

The fact that you're thinking about aliasing is a sign that it's flawed in the first place.

I disagree with this very much. Packaging a set of components together under a well organized namespace is (IMO) the Right Thing to Do. However, sometimes in order to do this right, you end up with long drawn out names which are a pain to type. Aliasing allows the user of your module to shorten the names to a more managable size, and at the same time allows the maintainer to keep their module namespace neat and tidy.

(And I know how you probably feel -- development names are tough to let go, it's easy to get attached to them through repeated exposure.)

Actually, we are not that tied to it yet. We are building this in anticipation of a particular $work project, so it is still a fairly localized change if we have to make it.

Personally, I liked the name "Tree::Simple" -- it immediately stood out among all the tree modules

Thanks, I really wanted to call it plain old "Tree" (which is what it was when it was only used internally at $work). My biggest problem with the name Tree::Simple is that when I first wrote it,.. it was fairly "Simple". It has now grown into much more (Tree::Simple::VisitorFactory, Tree::Simple::Manager, Tree::Simple::View, etc.) and so the name doesn't fit so well anymore.

This is part of the reason why we are leaning towards a name like Forest. It has lots of room to grow ;)

-stvn

[reply]