Re^2: splitting a source file

What's wrong with some simplicity?

Provided all you ever want to do is stuff some subroutines someplace and use them later, not much... but you give up namespaces, compile-time bindings, custom import, path management, and a few other features. You have to go through hoops to create your own classes. You don't learn how to use other modules..

Comment on Re^2: splitting a source file Download Code

Replies are listed 'Best First'.
Re^3: splitting a source file by KurtSchwind (Chaplain) on Oct 24, 2007 at 20:19 UTC
Just because someone uses a require doesn't mean that they forfeit the user of other modules. I used modules for years before writing my own. And for small apps, Namespaces isn't really a large factor. It's easy to over-engineer applications. Many times, someone just wants to write a bit of code that does the trick on a single machine where they are the user, the developer and the maintainer. Under these circumstances, I don't see why someone who is relatively new to perl should jump into creating modules and worrying about namespaces. Having said that, I will concede that there is never a better alternative to good coding standards and procedures. But if you really want to get there, it can happen a bit more organically. As soon as he runs into a namespace issue he'll be looking into modules. Let it wait until then. Right now, he needs to clean up the clutter a bit.	[reply]
Re^4: splitting a source file by rje (Deacon) on Oct 24, 2007 at 21:32 UTC
Right - one step at a time; just getting results with a minimum of effort can preserve momentum. It took me years before I "needed" modules. At the same time, it's good to know they're out there, even if you're not going to use them.	[reply]
Re^3: splitting a source file by bart (Canon) on Oct 25, 2007 at 09:14 UTC
It's his first time, let him start with require. It'll do for now. Later, in a next project, or in a rewrite, he can add use, packages and all the rest... But use is just an extension of require. Let him start simple.	[reply]