README.md in object-cache-0.0.2 vs README.md in object-cache-0.0.3

@@ -6,10 +6,11 @@
 * [Quick Start](#quick-start)
 * [Usage](#usage)
   * [marshaling data](#marshaling-data)
   * [ttl](#ttl)
   * [namespaced keys](#namespaced-keys)
+  * [key prefixes](#key-prefixes)
   * [redis replicas](#redis-replicas)
   * [core extension](#core-extension)
 * [License](#license)
 
 ## Installation
@@ -126,20 +127,72 @@
 returned object in the cache store. The provided namespace argument is still
 merged together with the file name and line number of the cache request, so you
 can re-use that same `email` namespace in different locations, without worrying
 about any naming collisions.
 
+#### key prefixes
+
+By default, the eventual key ending up in Redis is a 6-character long digest,
+based on the file name, line number, and optional key passed into the Cache
+object:
+
+```ruby
+Cache.new { 'hello world' }
+Cache.backend.keys # => ["22abcc"]
+```
+
+This makes working with keys quick and easy, without worying about conflicting
+keys.
+
+However, this does make it more difficult to selectively delete keys from the
+backend, if you want to purge the cache of specific keys, before their TTL
+expires.
+
+To support this use-case, you can use the `key_prefix` attribute:
+
+```ruby
+Cache.new(key_prefix: 'hello') { 'hello world' }
+Cache.backend.keys # => ["hello_22abcc"]
+```
+
+This allows you to selectively purge keys from Redis:
+
+```ruby
+Cache.backend.del('hello_')
+```
+
+You can also use the special value `:method_name` to dynamically set the key
+prefix based on where the cached object was created:
+
+```ruby
+Cache.new(key_prefix: :method_name) { 'hello world' }
+Cache.backend.keys # => ["test_key_prefix_method_name_22abcc"]
+```
+
+Or, use `:class_name` to group keys in the same class together:
+
+```ruby
+Cache.new(key_prefix: :class_name) { 'hello world' }
+Cache.backend.keys # => ["CacheTest_22abcc"]
+```
+
+You can also define these options globally:
+
+```ruby
+Cache.default_key_prefix = :method_name
+```
+
 #### redis replicas
 
 Before, we used the following setup to connect `Object::Cache` to a redis
 backend:
 
 ```ruby
 Cache.backend = Redis.new
 ```
 
-The Ruby Redis library has primary/replicas support [buit-in using Redis
+The Ruby Redis library has primary/replicas support [built-in using Redis
 Sentinel][sentinel].
 
 If however, you have your own setup, and want the writes and reads to be
 separated between different Redis instances, you can pass in a hash to the
 backend config, with a `primary` and `replicas` key:
@@ -149,11 +202,11 @@
 ```
 
 When writing the initial object to the backend, the `primary` Redis is used. On
 subsequent requests, a random replica is used to retrieve the stored value.
 
-The above example obiously only works if the replicas receive the written data
+The above example obviously only works if the replicas receive the written data
 from the primary instance.
 
 #### core extension
 
 Finally, if you want, you can extend `Object` with a `cache` method, for
@@ -165,11 +218,11 @@
 # these are the same:
 cache('hello', ttl: 60) { 'hello world' }
 Cache.new('hello', ttl: 60) { 'hello world' }
 ```
 
-Since the core extension adds the `cache` method to the `Object` class, you can
-also call this method directly on any instances inheriting from `Object`:
+You can also call this method directly on any instances inheriting from
+`Object`:
 
 ```ruby
 require 'object/cache/core_extension'
 
 'hello world'.cache(ttl: 60)