That's like asking for the chocolate back after you've made chocolate milk!

This post concerns a tragedy in API design. While it is often convenient to have your API receive compound data, it is a bad idea.

What is compound data?

A compound datum is an apparently atomic data item that it really not atomic. Here are two examples of API tragedy:

DBI

DBI->connect("dbi:mysql:database=sakila;host=localhost;post=3306",
    $username, $password);
[download]

The first argument to connect is compound data. It is a single string argument, but it contains important subelements:

1. dbi
2. mysql
3. database
4. host
5. port

so what?

well, take a look at register_db API, it expects you to supply things like "mysql" and "host" in separate parameters:

    __PACKAGE__->register_db(
      driver   => 'pg',
      database => 'my_db',
      host     => 'localhost',
      username => 'joeuser',
      password => 'mysecret',
    );
[download]

So, what happens if you've been using DBI and you have all your connect data in configuration files with DSN strings and then you decide you want to start using Rose::DB::Object? You have to find some way of getting the chocolate back from chocolate milk --- you have to break down the compound data in the dsn in order to get out the sub-elements.

DBIx::DBH

DBIx::DBH was written long ago to address this issue. You supply the sub-elements of the dsn and it forms the compound data for you.

HTML::Zoom

HTML::Zoom is a promising push-style templating system developed by Matt Trout. Let's take a look at how you select an HTML tag with id equal to "hithere":

$zoom->select('#hithere');
[download]

So "hithere" is compound data. The octothorpe is shorthand for id and "hithere" is the value of an id... that's two things packed into a single scalar.

suggested non-compound top-level API call

$zoom->id('hithere');
[download]

and similar to class lookdowns, etc.

The HTML::Element look_down() method had an excellent non-compound approach.

That being said, the current API meshes well with the jQuery API and it also intuitive for web designers, so there are definitely some reasons for why it is OK.

Relational Database Design

I dont have the time to get into all the terrifying ways that people overload single columns with compound data

Directory Trees

If you see a directory structure like:

drwxrwxrwx ... bugs-old
drwxrwxrwx ... bugs-new
drwxrwxrwx ... bugs-closed
[download]

you have compound data, which you need to "normalize" via bugs/old, bugs/new, bugs/closed

conclusion

I hope this post helped someone. Typically people either know this and dont need to be told or they dont know it and dont care :)

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.