Re^2: Singleton method wrappers for config file properties: Bad idea?

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

Comment on Re^2: Singleton method wrappers for config file properties: Bad idea?

Replies are listed 'Best First'.
Re^3: Singleton method wrappers for config file properties: Bad idea? by shmem (Chancellor) on Apr 01, 2017 at 13:40 UTC
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]
Re^3: Singleton method wrappers for config file properties: Bad idea? by haukex (Archbishop) on Apr 01, 2017 at 12:13 UTC
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]