> >> Well, then we have two possibilities:
> >> a) there is no String#prev
> >> b) there is a STring#prev with a preference.
> 
> > I strongly favor a): 
> 
> But note likewise that none of this applies to Integer...
> 
> > - String#succ is a convenience method. It is nice to have, but one
> >  should not conclude the necessity to have the reverse.
> 
> Whereas Integer#succ and Integer#prev are far more fundamental, and it would
> be nice to have fast implementations for when they are needed.
> 
> > - String#pred is not really necessary. Even a lot less than
> >  String#succ.
> 
> Integer#prev has a more or less equal footing with Integer#succ 
> 
> > - String#pred would require a lot of questionable distinction of
> >  cases. A lot more than String#succ. (The predecessor of "foo"
> >  might be "bar", "baz" or "zoo". What do we go for? Hacker 1: "bar"
> >  of course. Hacker 2: No "baz" is more reasonable. Hacker 3: "zoo" is
> >  what most people will expect.)
> 
> Integer#prev is well defined :)
> 
> Basically, the line should be drawn at "the analogy between String and
> Integer breaks down here" rather than "neither of them need a prev method".
> 
> (And while we're at it, IMO .pred(ecessor) is a more natural
> complement to .succ than .prev is)

So... ehh... I hate to beg the question, but before this thread gets
pounded into a nothing, let me summarize:

*) String#prev is controversial with minimal gain (though a fun
 exercise in Ruby skilz)

*) Integer#prev is well defined and an easy target

*) No one seems to think Integer#prev is a bad idea

Anyone object to the functionality/patch?  ;~)  -sc

-- 
Sean Chittenden