We love the conveniences provided by
extlib, we just don't love them at the same time and on top of each other. active_support is slow to load, has many dependencies, and is all intertwingled. We had too many collisions between
active_support 2.x and 3.x and
What gorillib gives you is clarity over what features are brought in. If you want to just get
require 'gorillib/object/blank'. No dependencies, no codependents.
- No creep: include only what you need
- No dependencies unless audaciously advertised.
- Upwards compatible with
active_supportcomponents have significantly more robust internationalization, and some functions have rich option sets in
active_supportvs. basic functionality in
gorillib. So the rule is if you were happy with
gorillibyou'll be happy with
active_support, but not vice-versa.
Gorillib has at least one powerful addition to the canon: the
Think of it like 'An ORM for JSON'. It's designed for data that spends as much time on the wire as it does in action -- things like API handlers or clients, data processing scripts, wukong jobs.
- serializes to/from JSON, TSV or plain hashes
- type converts when you need it, but doesn't complicate normal accessors
- upward compatible with ActiveModel
Requires only the following minimal set of libraries:
gorillib/object/blank-- fluent boolean methods
gorillib/array/extract_options-- get optional keyword args from a
gorillib/exception/raisers-- DRY exceptions:
requires @gorillib/base@ and the following additional libraries:
- Array extract_options!
- Hash extractable_options? (helper method)
- Array compact_blank, compact_blank!
- Array deep_compact, deep_compact!
- Date, Time to_flat
- Time parse_safely
- Enumerable sum
- Hash compact, compact!, compact_blank, compact_blank!
- Hash deep_compact, deep_compact!
- Hash deep_merge, deep_merge!
- Hash stringify_keys, stringify_keys!, symbolize_keys, symbolize_keys!
- Hash assert_valid_keys
- Hash reverse_merge, reverse_merge!
- Hash slice, slice!, extract!
- Hash Hash.zip
- Unless the top-level constant ::Log has been defined, opens a new Logger to STDERR and assigns it to ::Log
- Class class_attribute
gorillib/metaprogramming/remove_method required with class_attribute
- Module remove_possible_method, redefine_method
gorillib/metaprogramming/singleton_class required with class_attribute
- Kernel singleton_class
- Class# cattr_reader, cattr_writer, cattr_accessor
- Class# mattr_reader, mattr_writer, mattr_accessor
- Module# delegate
- Numeric clamp -- coerce a number to lie within a certain min/max
- Object blank?, present? (and specialized for all other classes)
- Object try
- Object try_dup
- String constantize
- String camelize
- String snakeize
- String underscore
- String demodulize
- String titleize
- String humainze
- Array as_sentence
- String truncate
Most of this code is ripped from active_support and extlib -- their license carries over. Everything else is Copyright (c) 2011 Infochimps. See LICENSE.md for further details.
Find this repo useful? Thanks! We love you! Find this repo nearly useful? Awesome! We'd love to have your help improving it. One way to help is to file an articulate well-reasoned bug report, feature proposal, or short story about gorillib on the Gorillib issue tracker. An even better way to help is to create a Patch or Pull Request
- Fork the project.
- Make your feature addition or bug fix.
- Add tests for it. This is important so I don't break it in a future version unintentionally.
- Commit, but please do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)
- Send a pull request to github.com/infochimps-labs
- If you'd like, drop a line to the mailing list for infochimps open-source projects, email@example.com
You might enjoy reading:
- Style Guide for Ruby
- Style Guide for README files (aka our README README)
- Style Guide for Repo Organization
- The Name of the Wind, by Patrick Rothfuss.
(Don't let the existence of a style guide -- or really any sense of modesty -- keep you from submitting a patch. If it departs from the norm we'll either fix it up, or in some cases propose tweaks, but at least others hitting the same issue can enjoy its benefits. We'd rather have worky code with a section that reads like cobol-accented perl than something broken)