Then what is the need or benefit of Rose::DB abstracting the DSNs?
We're going in circles now. As discussed earlier, the benefit is that the user is freed from having to remember obscure DSN formats, and can inspect the individual pieces easily. The "standardized names" I talked about in my hypothetical DBI example exist in Rose::DB: host, username, password, database, driver, etc. And don't forget, for those who do want to use DSN strings for some reason, Rose::DB will accept them as input in lieu of the individual components, and will produce them as output.
Furthermore, your continued characterization of Rose::DB objects as glorified structs or objectified DSNs means that you're either choosing to ignore or still don't understand the more substantial purpose of Rose::DB (especially as it relates to Rose::DB::Object, though some people do use Rose::DB on its own). Look at some of its methods: parse_interval(), format_timestamp(), next_value_in_sequence(), supports_select_from_subselect(), format_table_with_alias(), likes_uppercase_table_names(), auto_quote_column_name(), validate_boolean_keyword(). Common interface, database-specific implementations. Connecting to the database is just the start of Rose::DB's work.
In reply to Re^12: Avoiding compound data in software and system design
by siracusa
in thread Avoiding compound data in software and system design
by metaperl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |