Yes. DBD breaks out parts of the dsn, but that's its job! But it only looks at those parts it needs to find the right DBD::* module. It hands the rest over to that particular DBD::* module untouched. Because only that module knows what to do with them.

You're (still) missing the point. The "job" of a DBD module is to do database-specific stuff on behalf of DBI. Connecting to the database is "database specific stuff." Parsing separate pieces of connection information out of a string that's heretofore completely unknown and irrelevant to said database product is not. It's extra busywork. Were the DBD handed, say, an arbitrary hash of connection values, it'd merely have to pluck out the bits it needs. No string parsing required. Ditto for DBI "figuring out" what DBD to use by parsing the information out of this string. The same information would be better provided separately (e.g., as a hash key or a separate parameter)

Another analogy. Take a close look at TCP/IP packets. The application passes a data block. That gets wrapped in UDP or TCP headers and gets passed to the IP layer where IP headers get added. And that gets passed to the link layer where frame headers get added. To each of these layers, the packet from the layer above is just an opaque lump. And that's exactly how it should be.

This analogy is great because it highlights how far off track you've gotten. What you're describing is a form of serialization. Serialization is used to send compound information over a "linear" transport (e.g., a network connection). Serializing data only to pass it as a parameter to a local function call, which then has to de-serialize it, is dumb. No matter how many intermediate layers the arguments pass through, they can be passed along as-is, whether they're in a hash ref, an array ref, a list, or whatever. Serialization is not necessary or useful until/unless this data has to be written to or read from a serialized entity such as a file or network connection. (And even in that case, "arbitrarily formatted string" is much worse choice than, say, YAML, JSON, or any of the other standardized formats specifically designed for this purpose.)

In reply to Re^8: Avoiding compound data in software and system design by siracusa
in thread Avoiding compound data in software and system design by metaperl

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.