On 30/12/2008, at 11:55 AM, Damien Katz wrote:
Your argument about consistency and rigor being compromised is
unqualified. I see nothing more or less consistent or rigorous about
the current implementation versus other proposals, the rule as is is
easy to follow and use, and as far as I know has no inconsistencies.
Having no rule is simpler than the current rule. The API is
unnecessarily complicated by that rule. The fact that '_id' and '_rev'
would have underscores everywhere is not a rule, it is a matter of
identity, which is a fundamental concept i.e. a thing has a single name.
It is inconsistent because sometimes a document id is named 'id' and
sometimes '_id'. You claim that the name is consistent modulo the
application of the rule. I assert that is prima facie inconsistent.
As far as rigor being compromised, I assert that the current scheme
violates Ockham's Razor.
Furthermore, remember that this was brought up by Geir in the context
of a first approach to the API. I understand the rule and yet still
find it annoying to have to code against both 'id' and '_id' depending
on context. It has more cognitive load that having a single name for
that type of thing.
You claim that:
The current rule maybe not the most intuitive to a newbie, but it is
far more consistent and easier to work with then when using the
deeper APIs.
I think that fact that it is not the most intuitive to a newbie is a
telling point, given that I don't think the second phrase is true. How
are the deeper APIs made simpler and more consistent by having two
names for the id depending on context?
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies.
-- C. A. R. Hoare
