[jerf]

One of the things that has kept me away from the Ruby community is the way it simply takes as an axiom that OO === good; if it is OO it is good, if it is not OO it is bad. Re-read that and look at how many of his arguments are "X is not an object", with little further discussion of how that actually hurts you, just, "It's not OO" so apparently that concludes the argument that it is bad. (The class method comment links off to someone else who still comes down to a great degree to it not being "objects" properly. Yes, they may be overused, but pray tell what instance information the "sine" function takes? Oh, sorry, sine object.)

Your homework is to spend three months with Haskell learning idiomatic Haskell. Yes, it's not OO. Suck it up. You won't truly understand OO until you also understand not-OO.

[shepmaster]

Steve states: "objects > functions. At least in the context of getting stuff done in Ruby".

I completely agree that one should write idiomatic code. When you write Haskell, you write idiomatic Haskell. When you write Ruby, you should write idiomatic Ruby. Objects are idiomatic Ruby.

[chc]

Objects are not idiomatic in this particular case in Ruby. That's why we haven't been doing things this way for the past several years. Ruby's pseudo-functions (actually private methods on Object) and class/module functions are idiomatic. They are part of the Ruby language, and people use them all the time. Not only is this not the idiom in Rails, even vanilla Ruby projects avoid this, despite the lack of a framework pushing them in that direction. Ruby is very strongly OO, but idiomatic Ruby doesn't go out of its way to call attention to this fact. We don't fastidiously box every block just to make sure everything goes through an object interface, nor do we write 1.+(2) just to make it really clear to everyone that 1 is an object and + is a method. To create accessors, we just call attr_accessor — we don't do AttrAccessor.new(self).

The code Steve suggests here would be more idiomatic in Java than in Ruby. That's what this reminds me of — Java's endless array of classes-that-want-to-be-functions. Next somebody's going to realize that you might want to present dictionaries in different ways, so obviously you're going to want a DictionaryPresenterFactory to create a DictionaryPresenter to your specifications (because just having a method with that functionality would not be sufficiently OO, obviously).