Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re^2: Namespaces contiguous in the entirety

by QM (Parson)
on Sep 28, 2005 at 22:12 UTC ( [id://495925]=note: print w/replies, xml ) Need Help??


in reply to Re: Namespaces contiguous in the entirety
in thread Namespaces contiguous in the entirety

While you're at it, your lint process may want to catch that there should only be one package statement per file, and that package statement should match the filename, including path, from some entry in @INC, with directory separators becoming ::, and a .pm thrown on at the end.
My (limited) reading of modules leads me to think this is overkill. I've seen multiple package statements in a module for classes/namespaces derived from the main module, but the package was too small to worry about creating separate files. (I wonder how many modules in the core distribution make use of multiple package statements?)

-QM
--
Quantum Mechanics: The dreams stuff is made of

Replies are listed 'Best First'.
Re^3: Namespaces contiguous in the entirety
by Tanktalus (Canon) on Sep 28, 2005 at 23:20 UTC

    That's actually kind of my point. Convention says this is what you're supposed to do. However, convention also allows for alternatives. Convention says that each package appears once, at the top of a .pm file of the same name where ::'s are converted to directory separators. Which means that you should only have one package per file, and that you should never overlap with others' packages.

    In reality, there can be valid reasons for bucking convention. Packages that are too small to worry about separate files is a valid one. Hiding a package is another one - e.g., how mirod hides XML::Twig::Elt inside the XML/Twig.pm. Although in this case, it may be partly because XML::Twig and XML::Twig::Elt are so tightly intertwined that there could be fun times in trying to compile them in separate units. Other cases may have tightly tied packages where using the wrong one first can't resolve BEGIN blocks appropriately. Or other tightly tied packages where the other packages would take longer to locate on disk than is worth it.

    I really don't have a problem with the OP's suggestion. As long as there is a clean and easy way to turn it off when I know what I'm doing. Such as what TimToady suggests.

    use CGI::Application; class CGI::Application is also { # stuff we want to add to the CGI::Application namespace. };
    This says, "Yes, I know there is already a CGI::Application, but I'm the human, and you're the dumb computer, so do what I tell you." Well, that's what it says if I do it. It might not be so snarky if others do it ;-) I don't have an issue with this - the extra typing required for the rare time I do it seems like a reasonable trade-off.

    I'm not sure if there will be any perl 6 diagnostics for packages classes in the wrong file, though, as I had suggested to the OP.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2024-04-25 10:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found