One thing I noticed I actually need is ability to have secondary keys (which are usually unique, but that should not be a requirement), so that I can do lookups using one of two (or perhaps more) different keys.
Although one can create multiple cache elements for different keys (assuming keys were unique amongst themselves), problem is maintaining consistent LRU view; as well as ordering of insertion time.
But it might not be too difficult to extend existing structure by sub-classing (or composition if need be), to offer consistent view.
This will also have less overhead than creation of parallel cache elements.
One potential concern is how to handle this feature when implementing 'raw' elements; but we'll cross that bridge when we get there.
One thing I noticed I actually need is ability to have secondary keys (which are usually unique, but that should not be a requirement), so that I can do lookups using one of two (or perhaps more) different keys.
Although one can create multiple cache elements for different keys (assuming keys were unique amongst themselves), problem is maintaining consistent LRU view; as well as ordering of insertion time.
But it might not be too difficult to extend existing structure by sub-classing (or composition if need be), to offer consistent view.
This will also have less overhead than creation of parallel cache elements.
One potential concern is how to handle this feature when implementing 'raw' elements; but we'll cross that bridge when we get there.