On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote: > How about this? > > http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS FWIW I've read what you say about types, while this is good design to make things abstract, accessors are slower _and_ disallow many optimizations as it's a function call and that it may clobber all your pointers values. For types that _will_ be in the tight loops, we must make the types explicit or it'll bite us hard performance-wise. I'm thinking what is "struct object" or "struct commit" in git.git. It's likely that we will loose a *lot* of those types are opaque. struct object in git has not changed since 2006.06. struct commit hasn't since 2005.04 if you ignore { unsigned int indegree; void *util; } that if I'm correct are annotations, and is a problem we (I think) have to address differently anyways (I gave my proposal on this, I'm eager to hear about what other think on the subject). So if in git.git that _is_ a moving target we have had a 2 year old implementation for those types, it's that they're pretty well like this. It's IMNSHO on the matter that core structures of git _will_ have to be made explicit. I'm thinking objects and their "subtypes" (commits, trees, blobs). Maybe a couple of things on the same vein. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpzFh9tLP7po.pgp
Description: PGP signature
