Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: Main routines, unit tests, and sugar

by BrowserUk (Pope)
on Jun 16, 2013 at 15:16 UTC ( #1039210=note: print w/ replies, xml ) Need Help??


in reply to Re: Main routines, unit tests, and sugar
in thread Main routines, unit tests, and sugar

Reminds me of the guy that painted a bicycle on the side of his Hummer in an attempt to seem green. :)


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.


Comment on Re^2: Main routines, unit tests, and sugar
Re^3: Main routines, unit tests, and sugar
by vsespb (Hermit) on Jun 16, 2013 at 15:32 UTC

    Why is that?

    Any important code resides under one App::MyApp namespace, and not split across App::MyApp and myapp.pl

    Also different deploy methods can generate different binaries (some with hardcoded paths)

    Same used in Ruby ecosystems - binaries are autogenerate and are almost empty

    Also, if binary autogenerated it might not contain copyright/license notice

      Any important code resides under one App::MyApp namespace, and not split across App::MyApp and myapp.pl

      It was mostly humour, but ... you still need myapp.pl in order to invoke your application.

      Which means you added an extra file (your App::MyAPP.pm) -- and an extra level of callback trace to every error message, etc. etc. -- and made the (still) required file almost empty and what did you gain?

      IMO nothing. 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, use lib et al. -- just in order to see what it does; what its dependencies are ...

      That almost empty file, the .pl, is still used. What is the point in adding an extra file in order to make this one almost empty? There is no logical justification for it.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (16)
As of 2014-10-20 18:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (87 votes), past polls