in reply to Re^11: Avoiding compound data in software and system design
in thread Avoiding compound data in software and system design

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.

  • Comment on Re^12: Avoiding compound data in software and system design

Replies are listed 'Best First'.
Re^13: Avoiding compound data in software and system design
by BrowserUk (Patriarch) on Apr 30, 2010 at 18:43 UTC
    We're going in circles now. As discussed earlier,

    Not in circles. I keep asking the same question, because you haven't yet answered it.

    None of that consistutes a need.

    1. the user is freed from having to remember obscure DSN formats"

      They don't have to "remember". They just cut and paste from the appropriate DBD docs.

      Your way, they not only have to look up those docs to find out what each particular DBD requires; they also have to look up your docs to find out the "standardised names"; and then work out how to map bits of those opaque tokens to them.

      And then wonder what to do about the names they don't have bits for; and bits you don't have names for.

    2. and can inspect the individual pieces easily

      Why do they need to "inspect the pieces"? How will they use that ability?

      Just having that ability, 'because you can', isn't a reason for having it.

      Just being able to use that ability isn't a reason for having it.

      There has to be a purpose for using it. And you've obstinately failed to suggest even one.

    3. The "standardized names" I talked about in my hypothetical DBI example exist in Rose::DB: host, username, password, database, driver, etc

      Now that is a circular argument.

      They have to give you them in bits, because you have names for them.

      And you have names for them, so that they can break them into bits.

      But (again) for what purpose or benefit?

    4. And don't forget, for those who do want to use DSN strings for some reason, Rose::DB will accept them as input

      So, they don't need them. And neither do you I suggest.

      I've looked. Not exhaustively, but I have looked. And I cannot find one place where you do anything with those fields beyond set them and get them. Not one substantive flow control, validation, ... nada.

    Furthermore, your continued characterization of Rose::DB objects as glorified structs

    I have never characterised Rose::DB objects as such. Just the breaking apart of DSNs.

    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.
[reply]

In Section Meditations