This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: Humane blocks (and some math)
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
I just read over Martin Fowler's blog where he discusses "humane interfaces". Before I comment on that, some quick mathematical corrections.
The Array class has a grand total of 118 instance methods, not 78 as Martin says. However, 47 of those are inherited from Object, so that leaves us with 71. Of those, 8 are mixed in from Enumerable, leaving us with 63 instance methods. Of those, 2 are deprecated (Array#indexes, Array#indices) and 2 are aliases (Array#map! and Array#size), leaving us with a core of 59 instance methods. Note that of those, 7 are bang methods, meaning they're identical to their non-bang cousin, except that they modify the receiver (and tend to return nil), but I'll count them separately.
Back on point. His main point is that usability trumps some misguided notion that method count ought to be low. Difficult to test and maintain? Not really, not if you use TDD. Pragmatic? Definitely. You definitely want to help your users out with methods that are commonly used.
This is not to say that Array couldn't use some pruning. I have yet to find a use for Array#assoc, the Array#fetch method is of dubious value IMO when there are plenty of builtin (and intuitive, and short) ways to accomplish that same behavior, and Array#transpose seems too highly specialized to be a core method. But this is minor.
Where the Ruby community does tend to go overboard with regards to "interfaces" is the over use of blocks, usually implemented to avoid a call to Enumerable#map. This *does* create maintenance problems, as I've mentioned before. Sometimes they don't make any sense at all, such as Array#delete.
In fact, it was Array#delete that burned me just last night. Sometimes I use public methods as helper methods to some of my other public methods, e.g. Pathname#absolute? is simply the negation of Pathname#relative? - no need to write a separate implementation for each method. Normally this works fine and without issue.
However, on the C side of the house I was burned by the fact that rb_ary_delete() was yielding the deleted elements *even though I didn't want them to*. Fortunately my test suite caught it - I never would have thought to check that because it doesn't make any sense to me. The solution, and not the first time I've had to use it, is to use rb_funcall() instead.
Previous Topic
