Sun rejects orthogonal persistence for Java

[Rob Jellinghaus]

At 11:52 AM 9/16/1999 -0400, you wrote:
>>i.e. you don't ever want to
>>tell the future you anything more than you have to about what you are doing
>>now, since what you are doing now is so very likely to be wrong.  Hmm,
>>temporal information hiding???
>
>Rob:
>
>I find this comment confusing.  Computation is causal, in the sense that the
>effects of prior computation are visible to subsequent computation.  This is
>even true in systems that roll back -- we may abandon one of the causal
>universes, but as long as it exists the preceding computation is visible.

But visible to what extent?  I am addressing language-level persistence
rather than OS-level persistence, so I'm not sure we're speaking from the
same experience base, but here goes:

MarcS's comment about "transient" being the temporal version of "private"
is more or less what I was getting at.  Just as "private" may be a useful
way to decrease coupling in a running system (by enforcing separation of
components from each other), so may explicit specification of persistent
elements be a useful way to increase decoupling of the system over time (by
making future versions dependent on only a subset of the state of past
versions).

Yes, the prior computation still effects the subsequent computation.  The
issue is *how much* of the prior computation's state effects the subsequent
computation.  This is an explicit design issue, what I was calling
"temporal information hiding", and is one that needs as much thought and
language support as the more commonly labeled dimensions of information
hiding.

Of course, this introduces the problematic concept of a distinction between
running state and persisted state, but in some sense my point is that that
distinction is motivated not solely by historical reasons (i.e. the
inability to do full persistence at all), but also by design reasons (i.e.
the need to limit the coupling between the structure of prior system
versions and the structure of subsequent system versions, by limiting how
much prior structure gets persisted).

>Persistence gives a form of recoverability.  The main problem with it lies in
>the difficulties that arise when two independently persistent systems must
>interact.  This requires transactions, which in practice requires
violating the
>persistence model so that the transaction log will not be lost.  I suspect
that
>if there is an argument *against* persistence, it lies here.

That may well be, but it's a separate argument altogether :-)  And again,
I'm looking specifically at the language level here.  Oops, maybe it's the
same argument after all, in that an evolving system *is* in some sense two
separate systems--its prior version, and its subsequent version....

Cheers!
Rob