in reply to Singleton method wrappers for config file properties: Bad idea?

Personally, I would write a class representing the configuration, give it the ability to load its properties from a file, and then give the server object an instance of this config object. This allows the normal subclassing etc. mechanisms, for example one could overload the methods to allow the config to be loaded from a database instead of a file. I don't really see the advantage of "singleton methods" here. If you want to avoid writing $server->config->ip_address, then you could give the server class some convenience methods, e.g. $server->ip_address just calls the aforementioned method.

Replies are listed 'Best First'.
Re^2: Singleton method wrappers for config file properties: Bad idea?
by nysus (Parson) on Apr 01, 2017 at 12:02 UTC

    Yeah, good idea on turning it into a class. I've come to slowly learn that turning just about everything into a class is the way to go. Regarding the singleton methods, I think one big advantage is that every time I add a new property to the config file (I expect to have a couple dozen), I don't have to manually write a new accessor method.

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
    $nysus = $PM . ' ' . $MCF;
    Click here if you love Perl Monks

[reply]
      I don't have to manually write a new accessor method

      For a (mildly amusing) way to access values from a singleton config via methods, see using AUTOLOAD to access read-only data structures. But at the end, the core module Config.pm has all that is needed for a read-only config. Not everything has to be moosish.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
      I don't have to manually write a new accessor method.

      I don't think you necessarily do, either of these should work (untested):

      my @props = qw/ foo bar quz /;
for my $name (@props) {
    has $name => ( is => 'ro', ... );
}
# - or -
has [@props] => ( is => 'ro', ... );

      [download]

      Of course, if your config elements are different, then yeah, you'll have to account for those differences by adding new and different properties to your class for each one. That's part of the price you pay for using OO over a hashref, but you do gain some things (subclassing, argument checking, etc.).

[reply]
[d/l]

In Section Seekers of Perl Wisdom