couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Proposal: Extending immutability
Date Mon, 05 Jan 2009 22:21:08 GMT

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



Mime
View raw message