If one initializes an LRU or LU cache with seed data and those datum are never touched, then they are never evicted.

  (def C (lru-cache-factory {:a 1, :b 2} :limit 2))
  
  (-> C (assoc :c 3) (assoc :d 4) (assoc :e 5))

You would expect that the cache should contain only :d and :e, but it instead includes :a, :b, :d and :e! The problem is that seeds are never added to the eviction queue.

Cache c seeded with {:a nil} and accessed via (get c :a 42) returns 42 instead of nil. The reason for this is that the map vatAt delegates directly to the lookup protocol function without a has? guard.

Clache had an implementation of the LIRS http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.116.2184 strategy. This capability should be merged into core.cache also.

LIRS is implemented as a type only ATM. There should also be a corresponding factory fn.

(def c (clojure.core.cache/seed (FIFOCache. {} nil 1) {:a 1 :b 2}))

(defmethod print-method clojure.lang.PersistentQueue [q, w]
  (print-method '<- w)
  (print-method (seq q) w)
  (print-method '-< w))

(str c )
;=> "{:a 1, :b 2}, <-(:clojure.core.cache/free)-<"

(str (assoc c :c 3))
;=> "{:a 1, :c 3, :b 2}, <-(:c)-<"

The queue never gets the seed keys :a and :b and so they will never get expelled.

The evict method in the ProtocolCache needs implementation for FIFOCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc which in turn forms the basis for proper limited seeding. Currently only the BasicCache impl has evict.

The min-key method used to determine least tick explodes with:

clojure.lang.ArityException: Wrong number of args (1) passed to: core$min-key

This is a corner case that should be handled.

The evict method in the ProtocolCache needs implementation for LRUCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc which in turn forms the basis for proper limited seeding. Currently only the BasicCache impl has evict.

The evict method in the ProtocolCache needs implementation for TTLCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc. Currently only the BasicCache impl has evict.

The evict method in the ProtocolCache needs implementation for LUCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc which in turn forms the basis for proper limited seeding. Currently only the BasicCache impl has evict.

The core.cache functionality, with LIRS will be inline with Clache. A release should be cut and pushed to Maven central pending CCACHE-4.

Currently, lookup comes in only the 2-arg flavor (i.e. gimme a key and I'll give you a value or nil). The issue with this is that nil is potentially a legal value. Therefore, the 3-arg version logic is the same as the 3-arg `assoc` (.lookup this key not-found).

This change should propagate to all of the existing cache impls.

Clache had a buggy implementation of a cache backed by soft references. This capability should be explored further and implemented properly for core.cache.

To "overwrite" the value in an LRUCache, one uses assoc. Surprisingly, another k,v entry is evicted, even though the total number of items in the cache should not be increased by overwriting.

Demo:

(def C0 (lru-cache-factory {} :threshold 3))
; --> #<Var@7ec74910: {}>

(def C1 (-> C0 (assoc :a 1) (assoc :b 2) (assoc :c 3)))
; --> #<Var@315863e4: {:c 3, :b 2, :a 1}>

(-> C1 (assoc :a 4) (assoc :a 5) (assoc :a 6))
; --> {:a 6}

When I run lein check on my code, core.cache is a source of many reflective calls. Fortunately they don't seem to account for much time in my own profiling. But given that the purpose of a cache is to provide access to time-critical things, and the library can't easily anticipate the usage patterns of its users, it would be nice if we could remove these reflective calls, particularly where there does not appear to be any restriction to the use of the cache by doing so (that is, most of these appear to be from Java interop calls that are entirely inside the implementation of the caches).

Here's the output from lein check listing the reflective call sites:

Reflection warning, clojure/core/cache.clj:87 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:87 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:107 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:107 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:149 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:149 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:187 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:187 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:241 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:241 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:273 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:273 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:398 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:398 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:471 - reference to field poll can't be resolved.
Reflection warning, clojure/core/cache.clj:473 - call to remove can't be resolved.
Reflection warning, clojure/core/cache.clj:474 - call to remove can't be resolved.
Reflection warning, clojure/core/cache.clj:475 - reference to field poll can't be resolved.
Reflection warning, clojure/core/cache.clj:482 - reference to field iterator can't be resolved.
Reflection warning, clojure/core/cache.clj:482 - call to equiv can't be resolved.
Reflection warning, clojure/core/cache.clj:486 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:488 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:491 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:500 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:507 - call to put can't be resolved.
Reflection warning, clojure/core/cache.clj:508 - call to put can't be resolved.
Reflection warning, clojure/core/cache.clj:515 - call to remove can't be resolved.
Reflection warning, clojure/core/cache.clj:516 - call to remove can't be resolved.
Reflection warning, clojure/core/cache.clj:528 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:528 - reference to field get can't be resolved.
Reflection warning, clojure/core/cache.clj:562 - reference to field q can't be resolved.

There appears to be some inconsistency in the implementation of TTLCache. Specifically, it appears that if you lookup a value whose TTL has expired, but no new items have been added to the cache, it will still be present. But if you ask if the cache has? the value, it will report that it does not. For example:

```
user> (defn sleepy [e t] (Thread/sleep t) e)
#'user/sleepy
user> (-> (ttl-cache-factory {} :ttl 1000) (assoc :a 1)
(assoc :b 2)
(sleepy 2200)
(has? :a))
false
user> (-> (ttl-cache-factory {} :ttl 1000) (assoc :a 1)
(assoc :b 2)
(sleepy 2200)
(get :a))
1
```

So here we see, has? reports the value is no longer in the cache, but get will still give you the value. Unless I am misunderstanding the purpose or contract of these two functions, it seems that they should agree in whether or not a value is in the cache.

This also brings up the question of whether a value in a TTL cache that has passed the TTL should remain in the cache until the cache is updated. My expectation was that an item is not in the cache after the TTL has passed (ie, has? is currently correct). I can also see the argument that the TTL parameter is merely a lower bound on the amount of time it is cached; if it can be accommodated for longer, it will be (and thus lookup is currently correct).

As I said, my expectation was that things are no longer in the cache after the TTL, and I would still vote for this behavior as the correct one for a TTL cache, as it seems like a reasonable cache to use for things that can change out from under you, but a short period where it is out of date is acceptable (which is how I was trying to use it).

core.cache was originally Clache , but its inclusion into contrib means the latter is redundant. The Clache repo should indicate the move and change to a place for docs and examples. Likewise, a formal announcement should be made.

"limit" is used in other caches to represent quantity, for TTL it represents time. Using the same name is confusing