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