ggit

ggit copied to clipboard

Every go file in API seems to depend transitively or directly on every other one. It could hardly be coupled more tightly.

To have a real API we want disk and non-disk separate (at least separable).

Separating the object model types from the rest is a start.

I think we've been pretty careful to separate DiskRepository from the objects via Repository interface. It would definitely not be a bad idea to put repository implementations into their own package (e.g. api/repo), and it would be straightforward to separate out DiskRepository from everything else.

Yeah, but I wrote that description pre-coffee after a refactoring fight with Go.

I like the api/repo suggestion. After trying a couple different approaches, I think there are some prerequisite refactorings that we'll need to do first no matter what. The first of the first from what I saw will be the one I mentioned - separation of the object models and their construction interfaces from the rest of the behavior. If for no other reason than that it turns out to be the low-hanging fruit (pardon my Corporish).

I'm guessing you're referring to the fact that each object type has its own parse method, and that parse method presupposes the binary format for each object. Note that these methods do not assume anything about disk, they work on any old buffered byte stream, they are general.

If we start supporting a proprietary serialization protocol for git objects, then we can still keep the logic for this protocol in the API, and there is no need to create interfaces for business objects (yet). If the protocol is in another package, it may have trouble building up our business object structs. This can be addressed in several ways, one of which is constructors, and this still doesn't necessitate business object interfaces. (Note public constructors are probably necessary in the long-term to facilitate programmatic writing operations.)

With the ignorance of not having tried a refactoring, I ask: what is the case for business object interfaces?

When I said "interface," I didn't mean the Golang interface keyword. Or were you not talking about the Golang interface keyword either?

On Mon, Nov 5, 2012 at 11:12 AM, jbrukh [email protected] wrote:

I'm guessing you're referring to the fact that each object type has its own parse method, and that parse method presupposes the binary format for each object. Note that these methods do not assume anything about disk, they work on any old buffered byte stream, they are general.

If we start supporting a proprietary serialization protocol for git objects, then we can still keep the logic for this protocol in the API, and there is no need to create interfaces for business objects (yet). If the protocol is in another package, it may have trouble building up our business object structs. This can be addressed in several ways, one of which is constructors, and this still doesn't necessitate business object interfaces. (Note public constructors are probably necessary in the long-term to facilitate programmatic writing operations.)

With the ignorance of not having tried a refactoring, I ask: what is the case for business object interfaces?

— Reply to this email directly or view it on GitHubhttps://github.com/jbrukh/ggit/issues/48#issuecomment-10076393.