Re: To Extend, to Use, to Create

See also Config::Tiny and Net::Curl::Easy. If you want JSON see JSON::Tiny. If you really feel that you need to inherit see parent. But if i were in your shoes i would try to keep things simple: If you want a lib create a plain old module. Or consider a role using Role::Tiny. And XML still might be an option: See XML::LibXML::Simple. Still a bit better to read by humans than JSON.

ŤThe Crux of the Biscuit is the Apostropheť

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Comment on Re: To Extend, to Use, to Create Download Code

Replies are listed 'Best First'.
Re^2: To Extend, to Use, to Create by Fletch (Bishop) on Dec 07, 2020 at 19:11 UTC
Personal opinion I'd quibble with your last sentence, at least if we were to limit to "humans who program". Especially for deeply nested hashes I prefer reading the tidy'd output from (say) `jq . config.json` than trying to unroll an XML representation which is probably going to be much . . . "chattier". Then again I may have been biased by having to decode (say) Jenkins' XML configs (and other Java ecosystem offenders). Not to mention on the third hand I marginally like YAML better than JSON still for arbitrary applications in general, so . . . The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l]
Re^3: To Extend, to Use, to Create by karlgoethebier (Abbot) on Dec 08, 2020 at 07:32 UTC
"...deeply nested ..." Yes sure. But I'm still convinced that configuration files shouldn't be deeply nested. And writing JSON config files by hand? I'm not sure if this is a good idea. Considered harmful. "May be it's just a matter of taste" said the ape and bit into the soap ;-) (is bit simple past?) ŤThe Crux of the Biscuit is the Apostropheť `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l]
Re^3: To Extend, to Use, to Create by Bod (Parson) on Dec 07, 2020 at 22:22 UTC
I agree with you Fletch that JSON is more human readable than XML. But equals separated key/value pairs are even more human readable, even to humans who don't program. Sure, they are not able to hold nested data but that isn't always needed. Many years ago I created what is essentially a hierarchical database for recording rights of way entirely in XML with separate files for every entry. So my code has generated 100's of 1000's of XML files!	[reply]