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

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

Replies are listed 'Best First'.
Re^10: Avoiding compound data in software and system design
by siracusa (Friar) on Apr 28, 2010 at 14:12 UTC

    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.

[reply]

      In case you missed it, please see Re^5: Avoiding compound data in software and system design. The salient passage is:

      To achieve all that, you'd need more than just a hash. You'd need one flag per field to decide whether the key name should be prepended to the fields value. You'd need another value to ensure ordering. You'd need yet another flag to ensure that (for example) backslashes in pathnames got escaped for interpolation.

      Though the context of the post makes that clearer.

[reply]

In Section Meditations