fix hash and == for LibGit2.Oid

[JeffBezanson]

I happened to find these minor infelicities in the libgit2 code.

[yuyichao]

So it seems that this is not tested?

[JeffBezanson]

I guess so. Perhaps hashing and comparing these Oids is not even necessary; I'm hoping somebody who knows this code better can comment.

[jakebolewski]

We currently use the bytestring SHA's everywhere, but that should be transitioned over to using Oid's for some type safety.

[StefanKarpinski]

Food for thought on protocols. With implicit protocol satisfaction, this would silently fail to implement the Hashable protocol. With explicit statement, you could get an error that the protocol isn't satisfied. Either one would be better than this where it silently doesn't work, although I'm inclined to feel that the explicit case is better.

[JeffBezanson]

Point taken. However some careful design is needed. For example, I might implement hash and == methods, but forget e.g. to write <: Hashable on the type declaration, in which case you also lose checking. Defining methods inside protocol blocks can prevent this, but then you can't introduce a protocol that describes methods somebody else already implements without going back and editing their code. So I don't really know the answer yet.

[JeffBezanson]

I actually think just having

protocol Hashable
    hash(_, UInt)
    ==(_, _)
end

written down somewhere helps a lot with this. The docs for hash also describe this, but that doesn't seem to work as well psychologically. I can think of many reasons why this might be the case.

[StefanKarpinski]

Yeah, I'm still pretty up in the air about which is better myself. I'm slightly inclined towards explicit opt-in.

[JeffBezanson]

I'm fine with an explicit version if we can come up with a nice design.

To me, the key is that being able to ask whether type X implements a protocol is strictly separate from wanting X to implement the protocol. So to me it would be a shame if the core design tied these together.

[StefanKarpinski]

True, those are definitely distinct. Do you think it's a good idea to allow the programmer to express that they want to implement a protocol without implementing it? If so, which one does dispatch pay attention to?

[JeffBezanson]

The best thing I can think of currently is (1) build in the fully-implicit version, (2) be able to write something like @implements Array Iterable that will check Array <: Iterable and issue diagnostics. I realize this is exactly what I criticized above as insufficiently automatic to prevent problems like the one here with LibGit2.Oid, but it's the best I have so far.