On 06/01/2009, at 4:57 AM, Robert Dionne wrote:
First, I'm a little confused by the use of the phrase referential
transparency as I understand the more technical definition in the FP
literature (call a function twice on the same input and get the same
output), but I think I see the intended meaning, please clarify if
you have another meaning.
I'm using referential transparency in a conceptual manner - the idea
that the id + rev can be substituted for the document because the
reference is to an immutable value, so doc1 = doc2 is equivalent to
(id + rev)1 = (id + rev)2. If that equivalence holds even when design
docs and/or databases change (my proposal) then you can make stronger
claims about correctness, which enables simpler and more generic
reusable client facilities.
The property would be even more powerful if the rev was e.g. a hash of
the document. In fact, probabilistically this would be a substitute
for extending the document identity with view and database identities.
Do you have applications and/or envision use cases that are dynamic
enough that you want to track design doc changes? It seems to me
these are more a development time concern.
I know you subsequently answered this, but the issue is somewhat more
theoretical - if we extend immutability in this fashion then there are
simplifying benefits that allows such dynamic applications, even if we
can't think of them all now.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
A reasonable man adapts himself to suit his environment. An
unreasonable man persists in attempting to adapt his environment to
suit himself. Therefore, all progress depends on the unreasonable man.
-- George Bernard Shaw
