It's just an example.

A very poor example that does nothing to justify the need to objectify DSNs.

Let's just assume for a moment that there is a legitimate purpose for using two different RDBMSs in a single application. And ignore that you can just open two standard DBI connections to them. And that Rose::DB has some useful part to play in that scenario(*). Then what is the need or benefit of Rose::DB abstracting the DSNs? Either as hashes or objects?

• You cannot use the same hash/instance for both connections because they contain different information.
• The only even vaguely consistantly common aspects across even just a sizeable subset are: the constant 'dbi'. and the user & pass fields.
• And even if both connections have the latter two, it would probably be considered unwise to use the same userid and passwords for two different DBs.
• You cannot validate any of the fields except the constants.
• Beyond setting, getting and (re)serialising them, there are no useful methods that can be applied to them.

  Hence, they become nothing more than objectified structs.

There is no advantage in hashifying or objectifying them

And once you recognise that, there is certainly no benefit in trying to stuff multi-line serialisations of them into environment variables. And yes, I realise that some of those formats can be formatted as single lines, but have you ever tried editing them when formatted that way?

Which means you'd now need to use some kind of tool to edit, then compact, them before stuffing the env vars. And that's a nonsense. It defeats the simplicity of purpose that environment variables have had for 40 years or more.

And still you haven't given any specific reason for Rose::DB needing to have these "opaque tokens" broken out as structured entities rather than just leaving them as they are?

And I mean needing! Not just a capricious choice.

(*)(I'm not suggesting it doesn't, I just haven't gone into it enough to know one way or the other.)