README.md in uber-0.0.4 vs README.md in uber-0.0.5
- old
+ new
@@ -63,47 +63,53 @@
Usually DSL methods accept a number of options that can either be static values, symbolized instance method names, or blocks (lambdas/Procs).
Here's an example from Cells.
```ruby
-cache :show, tags: lambda { Tag.last }, expire_in: 5.mins, ttl: :time_to_live
+cache :show, tags: lambda { Tag.last }, expires_in: 5.mins, ttl: :time_to_live
```
-Usually, when processing these options, you'd have to check every option for its type, evaluate the `tag:` lambda in a particular context, call the `#time_to_live` instance method, etc.
+Usually, when processing these options, you'd have to check every option for its type, evaluate the `tags:` lambda in a particular context, call the `#time_to_live` instance method, etc.
This is abstracted in `Uber::Options` and could be implemented like this.
```ruby
-options = Uber::Options.new(tags: lambda { Tag.last }, expire_in: 5.mins, ttl: :time_to_live)
+require 'uber/options'
+
+options = Uber::Options.new(tags: lambda { Tag.last },
+ expires_in: 5.mins,
+ ttl: :time_to_live)
```
Just initialize `Options` with your actual options hash. While this usually happens on class level at compile-time, evaluating the hash happens at run-time.
```ruby
class User < ActiveRecord::Base # this could be any Ruby class.
# .. lots of code
- def time_to_live
+ def time_to_live(*args)
"n/a"
end
end
user = User.find(1)
-options.evaluate(user, *args) #=> {tags: "hot", expire_in: 300, ttl: "n/a"}
+options.evaluate(user, *args) #=> {tags: "hot", expires_in: 300, ttl: "n/a"}
```
## Evaluating Dynamic Options
To evaluate the options to a real hash, the following happens:
-* The `tags:` lambda is executed in `user` context (using `instance_exec`). This allows accessing instance variables or calling instance methods. All `*args` are passed as block parameters to the lambda.
+* The `tags:` lambda is executed in `user` context (using `instance_exec`). This allows accessing instance variables or calling instance methods.
* Nothing is done with `expires_in`'s value, it is static.
* `user.time_to_live?` is called as the symbol `:time_to_live` indicates that this is an instance method.
-The default behaviour is to treat `Proc`s, lambdas and symbolized `:method` names as dynamic options, everything else is considered static. This is a pattern well-known from Rails and other frameworks.
+The default behaviour is to treat `Proc`s, lambdas and symbolized `:method` names as dynamic options, everything else is considered static. Optional arguments from the `evaluate` call are passed in either as block or method arguments for dynamic options.
+This is a pattern well-known from Rails and other frameworks.
+
## Evaluating Elements
If you wanna evaluate a single option element, use `#eval`.
```ruby
@@ -125,15 +131,39 @@
## Performance
Evaluating an options hash can be time-consuming. When `Options` contains static elements only, it behaves *and performs* like an ordinary hash.
-Uber::Options.new volume: 9, track: lambda { |s| s.track }
+# Version
+When writing gems against other gems involves checking for versions and loading appropriate version strategies (e.g. "is Rails >= 4.0?". Uber gives you `Version` for easy, semantic version deciders.
-dynamic: true
+```ruby
+ version = Uber::Version.new("1.2.3")
+```
-only use for declarative assets, not at runtime (use a hash)
+The API currently gives you `>=` and `~`.
+
+```ruby
+ version >= "1.1" #=> true
+ version >= "1.3" #=> false
+```
+
+The `~` method does a semantic check (currently on major and minor level, only).
+
+```ruby
+ version.~ "1.1" #=> false
+ version.~ "1.2" #=> true
+ version.~ "1.3" #=> false
+```
+
+Accepting a list of versions, it makes it simple to check for multiple minor versions.
+
+```ruby
+ version.~ "1.1", "1.0" #=> false
+ version.~ "1.1", "1.2" #=> true
+```
+
# Undocumented Features
(Please don't read this!)
\ No newline at end of file