No, you wouldn't, because the specially-formatted DSN string never needs to be constructed at all, for any reason.

I see. So you're volunteering to go through and modify all the 600+ DBD::* modules; and all the modules that use them; and all the code written in the last 15 years that use them; just so that you can provide introspection of things that nobody will ever want to introspect?

Let's just pretend for a moment that we could re-write history, and DBI had specified that the first parameter to DBI was a hashref. And (say), the only required pair was dbi => Pg|MySQL|Whatever. And that each DBD was free to require whatever pairs it needed. What does that achieve?

You would have a hash rather than a string. That would make it easier to wrapover in your DSN object--though this parsing you speak of is hardly onerous. But then, as now, that wrapover is pointless.

• A hash is far easier to use than an object.

  $hash{ $key }++ is infinitely preferable to  $dsn->keySet( $key, $dsn->keyGet( $key ) + 1 );

• And apart from using clumsy OO syntax to get, set or iterate the contents of that hash, what else does that dns class do? What else could it do?

  You can't hope to validate all the possibilities. And there are no useful methods beyond get/set/iterate you could apply to it.

  Even ignoring that you'd:

  • either have to standardize the fields in the dsn.

    Which is impractical as each DBD has its own unique set of requirements

  • or eval the setters/getters into existance based upon what the user put in the hash.

    Which besides any problems with eval, means that

    1. DBDs would need to name all their fields.

       Which many own don't currently have, and neither need nor want to have;

    2. you would risk evaling the users typos into existance with absolutely no way to validate them.
• Ultimately, you'd have to provide a method that returned the attributes as a simple hash(ref) in order to pass it to DBI anyway.

  Unless you envisage passing your DSN object to DBI and have it pass it through to the DBDs (another breaking re-write).

  So then all the DBDs acquire yet another dependancy for no good purpose beyond the creation of OO tagliatelle.

So, even if we could ignore history, and turn back the clock to do things your way, there'd be no value in it. And a considerable downside of increased complexity and dependancies.

OO is fine and dandy when used properly, but using it to enforce a one-size-fits-all syntax fetish is no good use. Like all programming tools, the trick is to know when to use--and when not to.

You may think that I don't agree with you, because I haven't tried the KoolAid yet, but you'd be wrong. I tried your flavour of KoolAid (along with most others) a long time ago, I just didn't like it. Or rather, can tolorate all flavours, each is fine for certain occasions, but I see no good reason to limit myself (or others) to just one flavour. Of anything.