Bigdecimal does this too. There's some nifty extensions to standard
numeric classes, but you explicit required those features.
I'm not sure if framework vs. library distinction holds up. Most of
Rails is structured as libraries that are usable outside of Rails
anyway. (Not sure about the date / fixnum stuff, but I would assume
so.) I think it would be ok, however, if the standard requires for
Rails (or whatever) included the extensions, but there were other
require files available that didn't:
Another question is what if you wanted to extend standard classes for
use in the internal implementation of your library. As it stands now,
that's probably not a good idea. But with the proposed Ruby 2 namespace
feature it could be safe -- it the extension would only apply within
So how about this:
1. Don't change the behavior of existing stuff.
2. Adding new methods is OK, but document clearly and make those
From: Austin Ziegler [mailto:firstname.lastname@example.org]
Sent: Wednesday, August 24, 2005 6:40 PM
To: ruby-talk ML
Subject: Re: Extending Code Cleanly
On 8/24/05, David Brady <email@example.com> wrote:
Austin Ziegler wrote:
>Sometimes, as in #to_foo, it may be appropriate, but that should
>*probably* be done with:
> require 'foo'
> require 'foo/string'
I *REALLY* like this idiom!
require 'mymodule/standardmodule' # allow mymodule to make injections
Thanks. I didn't invent it, but it seems the *best* way to solve what
I'd said re: extending cleanly.
If Rails wanted to do this (as a library, not a framework), then it
might be require 'activerecord/date/fixnum' or something like that.
But that's just what *I* would do, and not what everyone would do.