in reply to including variables

When I need to share global things, most of all I want it to be maintainable. I put all of the global-things into one module with "getters" and "setters" to access them, and those subs are suspicious, checking for errors such as references to non-existent variables or attempts to set a value to the wrong data-type. I want all of the logic that actually sets or returns these values to occur in only one module – this one – and if something is wrong, anywhere, I want to see an exception being thrown such that I can get a traceback that leads me directly to the source-line where the otherwise-unfindable problem is. There are good CPAN modules to help ... the most obvious one being Moose or any of its lighter-weight cousins.

I also don't want things to be loaded dynamically, as in do, unless there is a compelling need for it. I literally want to know what the executing source-code consists of at all times, so that I do not have to be concerned whether a particular module had been "done yet" or not.

Replies are listed 'Best First'.
Re^2: including variables
by Your Mother (Archbishop) on Feb 17, 2018 at 23:28 UTC

    Please show us some code demonstrating this approach and the best way to literally know what some Perl source code consists of at all times.

Re^2: including variables
by LanX (Saint) on Feb 17, 2018 at 23:48 UTC
Re^2: including variables
by harangzsolt33 (Deacon) on Feb 18, 2018 at 00:39 UTC
    You don't want to load values dynamically. Well, then why don't you just use the system's environment to store those temporary values? How many values are we talking about and what are you planning to use them for? Anyway, the benefit is that if you have more than one perl program, then one can set the environment variables, and all the other perl programs that run after that will see those values and can easily access them using $ENV{'myvar'} I can't think of an easier solution than that.

    If by accident, you forget to set the environment variables, then your program can easily check to make sure they exist. For example, you could write:

    my $V = exists($ENV{'myvar'}) ? $ENV{'myvar'} : 'default value';

    OR

    exists($ENV{'myvar'}) or die...

      one can set the environment variables

      Not so easy to do. When run a Perl script gets its own copy of the system environment. It can't directly change the system's copy of environment variables so it can't easily set changes that will be seen by other scripts unless they are forked from the parent script (and thus inherit the parent's environment).

      Premature optimization is the root of all job security