Allow access to the entry (and its expiration) via get()

[nickbp]

Adds an entry() accessor, which operates in parallel to the existing deref() access to the underlying value.

(Resolves #6)

[nickbp]

Ping if you're around. Been using this version for the last few months and it's been working well.

[nickbp]

In order to unblock publishing other packages to crates.io that use this patch, I've created a retainer_nickbp crate with these changes.

[whitfin]

@nickbp what exactly is the use case behind accessing the entry itself?

Edit: nvm I saw the attached issue. Let me think about it a little and I'll get back to you after I try a few things out. Your changes work but I feel there may be a better option.

[nickbp]

Example usage in a DNS server here: https://git.sr.ht/~nickbp/originz/tree/main/item/src/cache/memory.rs#L53

If the entry is present, its remaining TTL in the cache is included in the DNS response

[whitfin]

Okay @nickbp, played around with it a bit...

I think it is a mistake that CacheEntryReadGuard<'a, V> currently derefs to V, it should probably deref to CacheEntry<V>, which would give you what you need. If you want to deref to V you can then just **guard.

What do you think about this approach?

[nickbp]

Sounds good to me!

[whitfin]

@nickbp after playing around with the various options, I have decided to mask CacheEntry<V> from the public API entirely, in favour of just CacheReadGuard<V> (which is just a rename of CacheEntryReadGuard<V>. This struct exposes both the expiration and value, and derefs to the value directly as before.

I stripped CacheEntry<V> out of return types too, which I don't think should really cause any issues (why would you care about an expiration after an entry is removed, for example?). Anything we want to surface in future can just live on the guard itself.

In a couple of places I use this crate, the usage actually cleaned up a little bit with these changes. Hopefully you can test and notice the same, while also getting access to the expiration values you needed. Please let me know if everything looks good, then I can merge and push it up!

I still have a few things I'm looking at for making it smoother, but I don't expect the public API to change much (or at all).

[whitfin]

I have published the changes in 0.3.0; I can follow up with any changes that might be required in future.

[nickbp]

This works great, thanks a ton!