Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Module naming issues

by dragonchild (Archbishop)
on Oct 20, 2005 at 01:24 UTC ( [id://501496]=perlquestion: print w/replies, xml ) Need Help??

dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

stvn and I decided to add a transparent persistence layer to Tree::Simple for work-related purposes. As most projects are wont to do, this ended up being a complete rewrite with better error-handling, a basic event model, transparent persistence to both a file and/or DB (or both simultaneously) and a straightened-out API. Because of the API changes (and cause stvn hates the name Tree::Simple), it was decided that this would be its own distro. And, thus the problems start.

My development names were "Forest" (for the distro) and "Tree"/"Tree::Binary" for the two trees I've implemented thus far. I obviously cannot upload with those names as Tree is owned by Schwern and Tree::Binary is owned by stvn. But, it's very likely that if you're using Forest, you haven't downloaded Tree (which hasn't been updated in years) or Tree::Binary (because it doesn't have all the really great features Forest does). And, it makes a lot more sense to call it "Tree" instead of "Forest::Tree" or "II::Tree", etc.

So, here's the idea stvn came up with - we call it Forest (containing the distro-level documentation, but no code), Forest::Tree, and Forest::Tree::Binary. (The persistence layer is already called Forest::Persist, with various subclasses from there.) And you will be able to do:

  • use Forest 'Tree'; (or something) which will load Forest::Tree, but alias it to Tree
  • use Forest; will load the whole distro, but provide no aliasing
  • use Forest ':all'; will load the whole thing and alias away the "Forest::"
Basically, Forest would act as a class loader of sorts. You don't have to use it, but I know we would.

Does anyone have an opinion on this? What about other ideas? Neither stvn and I don't feel comfortable asking Schwern for "Tree" because it's a TLN with a ton of other modules underneath it. I know I'd be miffed if someone came along and took over a TLN right from under (over?) me, especially when their stuff had nothing to do with mine.


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re: Module naming issues
by xdg (Monsignor) on Oct 20, 2005 at 03:50 UTC

    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.

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://501496]
Approved by GrandFather
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2024-04-24 00:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found