Justin B. wrote:
Care to elaborate? Not asking for a flame war or anything. I’ve used Rails
quite a bit and wanted to give Nitro a try on a toy project to see how I
like it, but I’ve also tried to use Facets before and found it to not be
well-documented, which irritated me.
The lack of documentation is the bane of many projects. There are
efforts underway to improve this in Nitro and related libraries.
I’ve used Nitro for a number of projects, and not had any issues that
weren’t simply from bugs (that have since been fixed) or my own misuse
due to lack of docs.
That a given library makes deep changes to core objects or behavior
should not be an issue if the nature and reasoning for those changes are
I expect that when people build, say, a Rails application, that they are
fully aware that the framework adds or munges certain aspects of Ruby,
and that some of the things they are able to (or not) do differs from
general Ruby programming.
As for certain features finding their way into the core language,
general discussion of RCRs may be indicative. It seems that if some
feature is easily added though conventional means (a mixin, for example)
then there is little enthusiasm for bundling it into the language.
For example, the to_json method is quite nice in certain cases, and has
been available via a ruby-json gem for over a year now. There’s no
compelling reason to make a part of Ruby itself, though. It’s too easy
for developers to just add it when they want to.
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.30secondrule.com - Building Better Tools