This is a compelling argument. I am +1 on using a consistent name throughout all contexts, by the way.
Be that _id or id, doesn't really bother me, but keeping it the same does. On Tue, Dec 30, 2008 at 12:16:19PM +1030, Antony Blakey wrote: > > 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 > > -- Noah Slater, http://tumbolia.org/nslater
