should the entry type be considered in PartialEq for Entry?

[thedavidmeister]

it's not considered in hashing (because it's in the hash of the Header), so should it be considered in equality?

[zippy]

Hmmm I wonder, this seems complicated. You might have two entry types that both can have the same content, and I can imaging that you want to use equality to compare them and sometimes have it fail, and sometimes not depending on the context.

How about we do compare the entry type in PartialEq because that's low level about the Entry object itself. And if you want to know if just the content is equal, you can just compare the hashes.

[thedavidmeister]

@zippy if your only concern was the entry content, couldn't you just do a.content() == b.content()?

i'd be worried that encouraging a.hash() == b.hash()

• obfuscates intent (the intent is to compare content)
• makes code needlessly fragile to future protocol/implementation changes

so then, maybe equality should include entry type after all?

OTOH, making equality of an entry include the entry type makes it based on something that isn't in the underlying data, as entry type lives in the header in the data - non-rust implementations could easily get this wrong if they're not paying attention

[thedavidmeister]

maybe relevant https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq

In other words, if two keys are equal, their hashes must also be equal.

[thedavidmeister]

FYI because partial eq has a custom implementation, so must the native hashing algo

implication is that (for example) that putting two entries with the same content but different types in any hash map will collide

implication of that is ???

[zippy]

This last bit is the important part. This makes me think we HAVE to make them not equal, because we have to be able to store those two entry objects in a rust hash and have them come back differentially.

[thedavidmeister]

mmm

#160 seems relevant to me too...

all the subtleties re: entries as a standalone chunk of data vs. when associated with a header :/

[jamesray1]

I wrote up some thoughts but they seemed a bit long and repetitive so I put them in this note:

https://hackmd.io/R8lUJLCXT8iW_bcVadLjRA