Repository navigation
Split GTReference into direct and symbolic variants #315
Description
Some types (e.g., unresolvedTarget) and some methods (e.g., -referenceByUpdatingTarget…) change their behavior based on whether the receiver is a direct or symbolic reference.
We should clearly represent the differences in the type system, using an abstract GTReference superclass for the commonalities.
Activity
tiennou commentedon Apr 9, 2015
First, is this still wanted ?
I took a quick look, and I'm cautious about unexpected "class changes". For example, picture a Git client with an array of references that contains that one direct reference. Now I do some weird thing using the CLI, and that reference becomes symbolic. My Git client is now the proud owner of a clunky weird not-direct-but-direct nonetheless reference which will likely misbehave (this reminds me of #407 BTW).
Given the behavioral differences between direct/symbolic, I'm not sure it's worth to duplicate those 2 method just to enforce type-correctness (especially since that correctness can go out of the window anytime).
jspahrsummers commentedon Apr 10, 2015
We'd like to live in a world where libgit2 and ObjectiveGit objects are just immutable values, so changing the type of the reference on disk shouldn't affect its object representation anyways.
IMO, the behavior differences between direct and symbolic are the reason to have different types. They behave differently and mean different things, so they should look different too.
tiennou commentedon Apr 10, 2015
Yeah, I can see how trying to treat everything as immutable gives clear benefits for concurrency, but I don't get how this can work together with different types. I mean, what should we do if, as I explained above, one of those references' type changes below us ? Remap the class at runtime ? That seems opposed to the immutability we're aiming for...
The other subclass-y way would be to create the reference, stash its oid/target/name/whatever at initialization so we can be immutable, and call it a day. If the reference goes away from below, we can keep working, but it seems to duplicate things that libgit2 should handle (and maybe it does exactly that, and I'm just being clueless ;-)).
jspahrsummers commentedon Apr 10, 2015
The reference object can get out-of-date, but it should never become invalid due to an underlying change. We simply won't be watching for any such changes, so we won't know when they'd occur anyways.
If you wanted to manipulate a symbolic reference, but it got changed, I assume we would just generate an error. That's the sane thing to do no matter what, because it communicates to the caller that their expectations about behavior may be invalidated.
mdiep commentedon Apr 10, 2015
FWIW SwiftGit2 only exposes direct references. If it encounters a symbolic reference, it resolves it and returns the direct reference. That seemed to play the best with value semantics since you need to resolve to get the actual target.