Packages

pudge on 2002-05-03T17:06:08

Wow. I am getting a lot of people telling me it is wrong/jarring/ungood/etc. to put "package Slash::SOAP::Journal" inside of a program. That I should put that code in a module instead, because, after all, it's a package!

Where do these people get such unreasonable ideas?

---

A package not in a module...

jweveland on 2002-05-03T17:58:56

It does seem odd to me... this looks like a good learning opportunity, so I'll bite. Under which circumstances is this useful? Things that come to mind are:

1) Differentiation of namespaces within a program?

2) Private class/object definition/functions w/ no chance of re-use by other code?

3) Other motives?

Jon

Re:A package not in a module...

pudge on 2002-05-03T18:34:30

In this case, SOAP::Lite requires a class name to dispatch to. So rather than writing a whole module that will only be used by this one call -- or worse, providing SOAP access to everything in the program -- I just add a package in the middle of my program, with only the symbols for SOAP in it.

There are many other reasons, too. I don't have time now, perhaps others can mention some.

Warning: Crack use is up

jjohn on 2002-05-03T19:12:16

As much of a style Nazi as I am about Perl, having multiple packages in a file is perfectly legimate if the packages are related. Many DBD modules do this. SOAP::Lite does this. When dealing with XML::Parser, you often need to define your own package for callbacks. It's convenient and often sensible. Packages are simply namespaces. They cost nothing to use. Would you rather have one big bookcase or several smaller ones? Depends on your dwelling.

Another guilty party

Fletch on 2002-05-03T18:55:16

I've done similar things, but I tend to cordon them off inside an anonymous block.

## blah, blah, blah
{
  package Fooblitz;

  ## fooble, fooble, foo
}

## ...
Fooble->zortz( 42 );

Tell 'em to bugger off.

clintp on 2002-05-03T21:38:39

There's *lots* of good reasons to use a package declaration without having a separate module.

Some that come to mind are small tie classes, overloads, and object classes. Also, when you want to "inline" a module for distribution purposes.

The camel is clear

jdavidb on 2002-05-03T22:08:38

I believe the camel says a package is usually a class, they usually have the same name, it usually begins with a capital letter, there is usually one package per file, a package is usually a module, and so on. Usually. Not always.

Anyone who's programmed Java knows sometimes you have extra classes in a file.

Testing and POD, but still useful

2shortplanks on 2002-05-04T09:33:05

One of the major reasons that I normally use the one package one file rule is that it allows easier testing. It's a seperate block. It's easier to test. Yey!

The other reason is that if I stick it in a seperate file then I can document it with POD. I can't do that in the middle of some other class (and even at the end it looks wrong)

OTOH, sometimes you don't need to document something in the POD - I wouldn't enforce you to document every private method (you might want to hide the interface) and therefore I shouldn't force you to document it just because it's in a different namespace.

Infact, the only module I've ever uploaded to CPAN uses an 'inner class'. I needed a tied filehandle to capture the output of Test::Builder. No-one cares that I'm using it - it doesn't effect your code - so it's not mentioned in the POD. And I can't test it alone!