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.)

You're (still) missing the point.

No. I'm not.

What you're describing is a form of serialization.

No. It isn't Serialisation would mean that the data existed in some structured form at the application level. It doesn't. Because it doesn't need to be known at that level. The envelopes are added as you descend through the layers; information that only that layer of encapsulation is party to. Added on the way in, stripped away on the way out.

Read the RFCs. And if that's too difficult for you, start here. And make special study of the contents of the box on the right hand side.

It is that encapsulation that allows IPv6 to be inserted into the stack underneath applications, without the applications needing to know anything about it. If those envelopes existed as structures at the application level, every application would have to be modified in order to use IPv6. Say what you will about the guys that invented that stuff--they may be old and grey, but they knew what they were doing.

And what you're doing in Rose::DB, by breaking the encapsulation of DSNs is exactly analogous to that. It is unnecessary, pointless and creates work for the application programmer. Your users. The OP for instance!

I know you think you know better, but 5 years or 10 from now, the penny will drop and you'll get it. Till then, we'd best just agree to differ, because you obviously aren't getting it now.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

And what you're doing in Rose::DB, by breaking the encapsulation of DSNs is exactly analogous to that. It is unnecessary, pointless and creates work for the application programmer. Your users. The OP for instance!

I'm not breaking any encapsulation. These separate pieces of information (host, port, database name, etc.) are necessarily in the domain of the person writing the code to work with a database. It's not like these are some internal details that the DBI user doesn't need to know or concern himself with. Then the DBI user has to take these discrete pieces of information and serialize them into an obscurely formatted string, with a different format for each database. Again, the DBI user has to do this himself! DBI is not doing it for him. There is no "encapsulation" service being provided here. Only then will DBI accept this information, which it will then pass through to the DBD, which then has to deserialize it. It's completely pointless.

And again, the "pass through with no knowledge of its contents" bit that you keep going back to is completely orthogonal to the form of the data. It could just as easily be done with any other, more sensible, non-serialized data structure.

It's much easier for the user if he can deal with these pieces of information as is most natural, i.e., as separate entities, without ever having to deal with this nasty aspect of the DBI API that requires them to be serialized. What the original poster is complaining about is the exact opposite of what you claim: DBI's pointless and variable serialization of the DSN, not other module's attempts to help deal with it.

I know you think you know better, but 5 years or 10 from now, the penny will drop and you'll get it. Till then, we'd best just agree to differ, because you obviously aren't getting it now.

Right back at you.