Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Module naming problems, or time ill spent.

by Dog and Pony (Priest)
on Jun 12, 2002 at 22:32 UTC ( #174050=perlmeditation: print w/ replies, xml ) Need Help??

Once upon a time...

... I was working with java. Now I (mainly) don't, and I do not really miss it much. I liked java, and I still do, but as long as I have for instance perl instead, I'm fine. I still have some tasks do to that require poking in java systems, so I keep my java knowledge up to date, or at least, I don't let them stagnate too hard.

In java, everything is an object, and thus, everything you write is classes. They may still be purely functional classes, containing only static methods that don't use any object behaviour, but you still put everything in a class. The difference (in perl terms) is when you do Module::function(), that is what we called a static method, and when you have an object that you do $object->method(), that is a ``real'' method.

Below here, I will take some small liberties with the definitions of modules, classes and suchlike. When I write modules, they are most oftenly classes too, even though I do know that a module need not have any class in it at all. Depending on your view, this may be viewed as semantics - to java, it would still be classes, in perl they are not. Just so you follow me along later here.

In effect, it would quite be as if everything you wrote was put into .pm files, or modules. Like in perl, you can put several classes (packages) in one module, but you can't, in java, have any .pl files. This is not really a problem, since all you have to do to get your ``.pl'' file is create a class (or ``module'') with a main method in it, much like in C, and you take it from there. It does take a little more effort though, as you must declare the class and all that, but with some templates or macros, you're fine.

Get to the point, already!

Anyhow, in java, since you do small things there too, you create a couple of classes when you write a program. You create Foo.java, Bar.java, and Baz.java, define main in Foo, and off you go. For bigger projects, you can qualify your classes via longer search paths - it is called packages. So the real name of the classes is perhaps wolf.ant.Foo, wolf.ant.Bar etc. A recommended practice is to put your company's domain backwards there, as in org.perlmonks.Foo.

What I am slowly getting at is that, in java, I used to create the classes Foo, Bar and Baz, and didn't really qualify them more than that. Not so in perl.

I think I've gotten a bad case of the CPAN's, in this case, when I do write a module, or a set of modules, I try to figure out where it would fit if there is a fitting category, or at least name it in with a top- and subname. Examples would be, if I wanted to write some text munging module, a fitting name might be Text::Munge, perhaps?

Yes? That is good, isn't it?

Well, yes. At least if the module, unlikely as it is, would ever turn up on CPAN. The problem at hand, is that I seem to spend waaay too much time on aptly naming my modules than it is worth, especially before I have any idea if it would end up on CPAN. I have yet to produce anything worthy of going there, which may be a hint.

Still, I somehow feel that I must name it in a good way. This can cause problems. I am recently toying around a little with a small set of modules that I thought would handle a little testing, write other module stubs and a little such from certain data. Nothing really serious, but it really struck me how much time I spent on figuring out a good name for the whole bundle.

For those that wonder, yes, I am aware of ExtUtils::ModuleMaker, and all the Test:: modules, it is in no way a replacement, just something that I figured will save me some extra time, and allow me to be lazy. If I get around to getting something that actually does any of that together, you will be the first to know.

As you may start to suspect. so far I have wasted time instead of saving it.

The problems I have

Being quite OO-oriented, for good and for bad, I usually write my stuff with objects and classes. Perl has taken some of that out of me, when it is really not necessary, but I still like the OO way of doing things. So I have a set of classes, each in their own module for clarity, and then it started.

I could name my module set Test::X[::X], which is quite fitting for where I started - I wanted to help out my test writing. Then I realized that I could also do Module stubs (trying to write the tests first, why not provide fitting stubs too, probably with ExtUtils::ModuleMaker?). The namespace Test::X suddenly didn't fit anymore.

Well, how about Module::X then? That is a little bit better, I could go Module::Test::X, and Module::Create::X, perhaps. There is still more. Without bothering with any more detail, let's just say that I really am touching at least three different top categories here, if I should name everything ``right''.

Since my ideas, the possibilities, and all such grows and shrinks as I try this or that, or think things through, this process can go on and on forever. Just because I want it to fit in. And if you wonder why I just don't rip it apart (I still might), that was because it everything produced comes from a common source. Which might give an apt name in itself, but then, you could also just use this one...

Of course I worry too much. I just realized the full impact of it. :)

The solution, as I see it

Well, upon realizing this, I also understood that I shouldn't have forgotten my old, java style of doing things so easily.

I should not really give a d*mn about what ``category'' it should be put in, unless it is blatantly obvious from the start. I should just create the modules, or classes, I see fit, give them a name like Test, Write, etc, or whatever I feel is correctly describing it inside my bundle. Then, after creating new modules, removing them, merged them and split them as happens during refactoring and as the work progresses, when it all works it should come down to two alternatives:

  • Either it is now obvious what top name it should have, or it should at least be a few to choose from.

  • Or it may not. In which case all is still not lost. I could ask people that are lots wiser than me, such as the very experienced people that hang out at this very place. You could probably come up with good suggestions on what to call it. Or as a last resort, some releases on CPAN are releases under Bundle:: with several different names under that. If no other option would be available, that is one last resort.

How about you?

I didn't only post this to whine about my problems. Partly, I also wanted others, if there are any, with the same problem to at least stop and think for a while, they too.

But most importantly, I wanted to ask a few questions:

  • Have any of you had the same problems? If so, how do you tackle it?

  • Is this really a problem, or was I doing the right thing all along? I have come to one conclusion, which may be the real error.

  • If it is a problem, have I come up with the correct solution, or do you have better suggestions?

Also note that while I am not writing modules to end up on CPAN or anything like that, I still would like my modules to follow the current standard, and if anything I ever produce would be of use to any other, I want to make sure they can use it. Also, even when using your own private module at home, it is nice if it kind of fits in the rest of the pattern.

Thank you for your time. :)


You have moved into a dark place.
It is pitch black. You are likely to be eaten by a pantomime goose.

Comment on Module naming problems, or time ill spent.
Select or Download Code
(ichi) Re: Module naming problems, or time ill spent.
by ichimunki (Priest) on Jun 12, 2002 at 22:55 UTC
    I've been spending a lot more time programming in Ruby lately, but I have OO Perl (and merlyn's 'perlboot' intro) to thank for having a hope in heck of doing OO anything. In Ruby or Perl, if my classes are specific to the application at hand, I would make that my namespace and then group functions or objects accordingly. Say my application was a tool for writing books, I'd make package names like BookMaster::TOC (for managing tables of contents), BookMaster::Chapter (for managing chapters), and BookMaster::DB (for interfacing with a DB).

    Now, if I found that I had some general utility function that was important to me-- suppose I were making a linked list class to make it so I could store each paragraph in a chapter in a list that would be more efficient to insert and delete items from than a vanilla array, then I might look on CPAN and see if there is a fitting namespace, like List::* and then call my class List::Linked.

    And just to soothe your naming concerns, there is a whole big section on naming variables and stuff in "Code Complete". So you're not the first person to take it seriously. :)

Re: Module naming problems, or time ill spent.
by vladb (Vicar) on Jun 12, 2002 at 23:43 UTC
    Clearly there are Perlish way to do things when you code in Perl and Java'ish way to do things when you code in Java. While there might be common paradigms (we should remember that Perl is a compilation of various 'better' practices initially introduced in other languages), I feel for the most time it is best to not run across the border too much.

    Having said that, I don't think it's a good idea to wrap any tiny Perl script around a bunch of OO objects. There is a time and place for every approach. Java, however, was so designed as to rely heavily on OO and work in that 'framework'. Unlike Perl, in Java existence outside an object/class is not possible. In many aspects I sympathize with this approach. On the other hand, however, the task of devising proper OO structures for every little problem/script is at times daunting.

    Speaking of naming, I recall it is a norm to see Java packages named as 'so.and.so.and.such' - basically, have multiple nested packages/classes. Whereas this works for Java, I don't see this deep nesting being useful in Perl. This partly stems from the fact that in Perl the number of 'core' objects is significantly less. Instead, in Java, everywhere you look is an object. Hence, the complex package naming scheme. A similar approach in Perl is simply not warranted. The need for a similar naming convention was engineered out of Perl (it doesn't rely as heavily on objects and etc).

    _____________________
    # Under Construction

      Regarding nested packages: I've actually seen more nesting in Perl packages than in Java ones. For instance, the java.io package has a twisty maze of relationships but all the classes are in the same package.

      One of the features making java package names a little longer is that by convention they're organized so nobody will step on any other namespace. You do this by organizing your code under your reversed domain name. So I work at optiron.com; our code is all under the com.optiron hierarchy. So before you've even applied logic you're two levels deep!

      That said, IME once you get to four deep you start getting the hacker equivalent of deep sea diving pressure, forcing you back up the tree to lighter waters :-)

      Chris
      M-x auto-bs-mode

Re: Module naming problems, or time ill spent.
by coreolyn (Parson) on Jun 13, 2002 at 14:11 UTC

    I too spend possibly more time than is efficient breaking out my code in both languages into packages/modules. IMHO I think if CPAN adopted the fronting of unique namespace to the modules it would allow for more diversity of solutions as well as allowing for easier identification of it's source ( name brand reliability so to speak ).

    One of the best parts of the OO paradigm is reusability, and In the applications I support I'm not seeing that aspect taken advantage of much at all. When I'm naming my packages or modules I am more concerned with keeping the abstraction of common components that can be yanked and replaced grouped together, rather than strictly focusing on functionality. I have found that by doing as such in either language my tool box is expanded with every application I put together.

    coreolyn

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://174050]
Approved by elusion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (9)
As of 2014-12-26 12:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (171 votes), past polls