in reply to Re^4: Main routines, unit tests, and sugar
in thread Main routines, unit tests, and sugar
Well, if the application is small enought to fit to one file, your arguments are valid
If application already consists of several files (i.e. it's not a small 500 lines script), the benefits I described outweigh that fact that you need another file
You added the need to chase off and track through where this module file lives -- not always obvious with lib, site/lib, site/vendor/lib
It must be irrelevant if we talk about CPAN deploy. More that that, if user has a mess with @INC dir, it's actually better to have all application files in one @INC dir, than having half of application is @INC and half in bin (/usr/bin, /usr/local/bin/ ~/bin /opt/myapp/bin etc) (if we assume that there is a mess with @INC, we can assume there is a mess with $PATH too)
Having site/lib, site/vendor/lib is actually a feature, so people can deploy with CPAN or with OS package manager at same time, it's an advantage
extra file
Minor issue, if you already have several files
an extra level of callback trace
There won't be extra level of stacktrace if you just split code to files. Extra level added if you split it to subroutines
So it's valid argument if we talk about having some startup code in one "main" subroutine vs having some code unwrapped to subroutine in main package
callback trace to every error message
Imho stacktrace should appear if unexpected/programmer error happened (assertion, like "confess"), otherwise there should be clear error message and no stacktrace is needed. But it's probably matter of script quality
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^6: Main routines, unit tests, and sugar
by BrowserUk (Patriarch) on Jun 16, 2013 at 17:44 UTC |