This is one example of many where we ask the wrong question on the assumption that the question we ask will have the same result as the question we should ask. My insurance company should ask something like "are you a safe driver?" or if worried this might be too abusable, something like "do you have someone(s) you care about deeply?" Seems that might be closer to what they want to know, yes? It's just too much trouble to ask the right question.
Why else might someone ask me, to stay on this topic, why I'm married? Maybe they want to know if I'm likely to go out on a date with them. Maybe they want to know if there's someone who will take over my estate (what little there is of it) when I die. Maybe they want to know if they'll need to pay for more moving expenses if they hire me. Maybe they want to know if I'm gay. People do these this without thinking. I could be married to someone who has no problem with me dating other women; I could have signed a contract with my wife preventing her from taking over my possessions; I could be married but not live with my wife; I could live in a country where gay marriages are legal. We rarely ask the right question.
A contract or a biography might provide us with answers to all our questions about someone, but we're too lazy to read those each time we want to know something. In fact, we're too lazy to ask the question that's on our mind. A callback function is the programmatic answer to this; you provide a means of asking questions as they come up, and you answer the questions exactly as needed. You don't provide up-front a definition of all possible scenarios (as might be the case if you handed someone your biography), and you still need to be asked the right question.
Consider a database application that wants to put a little red star next to "required fields" and consider the case where a field is required only if another field has a certain value. For example, the "state" field is required only if you indicate your country to be "United States of America." We cannot truthfully indicate in the database metadata that the state field is always required, nor that it is never required. We could provide a callback, however. What could go wrong? The problem with a callback is that you need to know when the answer might change. Sometimes you don't know. For all you know, the callback could change every time; maybe it's based on a random number, maybe it's based on the time of day; maybe someone is actively changing the rules every few minutes. Should you constantly ask? Ask only when something "obvious" changes? If the rule changes, should you be notified to re-ask? But how can anyone know to notify you unless they know you care about the answer to a question, and that the answer (not just the rule) will have changed in a case you care about?
When it comes down to questions about your life, answers are constantly changing. You shouldn't have to notify your insurance company every day to call you to ask you every question on the form, just in case.
In math and programming languages, there's a concept of 'deterministic' functions; that is, questions whose answer depends only on the question itself. "What is 2 + 2" does not change depending on the time of day. You can ask it once, and know the answer depended only on the values (2 and 2) you gave it. Generally, you can require that the validity condition on information be deterministic; that is, checking to make sure that information is valid shouldn't be dependent on the mood of the program. When you try to change the validity condition on existing information, your change should be refused if any existing information would fail the test. Easy enough.
But what do we do about something like "are you alive?" The question obviously depends on someone's "state", and "state" changes constantly. Some questions we're asked aren't deterministic, and can't be. The problem's not solved.
[Temporary end of thought-stream?]
