[ruby-core:103616] [Ruby master Feature#17830] Add Integer#previous and Integer#prev

Issue #17830 has been updated by rafasoares (Rafael Soares).


sawa (Tsuyoshi Sawada) wrote in #note-4:
> > I think Integer#pred is great as the inverse of #succ, but it reads a bit weird as the inverse of #next, which might be preferable for those going for a more "reads like English" approach.
> 
> I do not understand this logic. If "predecessor" and "successor" sound good as a pair, why does that go against reads-like-English approach?

Because `pred` isn't an actual word. Any abbreviation adds cognitive load, since you have to think about what it means -- if we're going to get really technical about it.

> Your point should rather be that "next" lacks its counterpart. That would be more understandable. Against such claim, I have the following opinions.

That **is** my point.

> 1. If your aim is to retain symmetry in the terminology system by supplementing a missing counterpart, then there may be a room for claiming for "prev", but not "previous", as we already have "succ" and "pred" in abbreviated form instead of "successor" and "predecessor". Introducing "previous" would break symmetry.

I agree to an extend. `previous` reads better and would be more easily guessable for newcomers. I personally prefer `prev` for shortness and symmetry, but I'm not agains the more "verbose", yet clearer, alternative - for completeness.

> 2. The use of terminology "succ" or "successor" is probably following the tradition of set theoretic definition of natural numbers, and hence more legitimate than "next". Just concentrate on "succ", and forget about "next". Then, you already have the counterpart "pred".

I don't know about you, but "the tradition of set theoretic definition of natural numbers" is not something I keep in mind when developing web applications for my day job...

> On top of that, my understanding is that Ruby encourages the use of internal iterators, which makes the use of successor and predecessor less frequent in the first place. In most cases, it is preferable to avoid using them, or replace the relevant code with `with_index`.

I'm not talking about iteration, though. Only when you need, or just want, a more readable alternative to `(my_number - 1)`.

Just to reiterate, the main reason why I think this is important and makes sense is because of Ruby's ideals (emphasis mine):
* (...) a focus on *simplicity and productivity* .
* It has an elegant syntax that is *natural to read* and easy to write.
* He [matz] has often said that he is “trying to make Ruby *natural, not simple*” 

From https://www.ruby-lang.org and https://www.ruby-lang.org/en/about/

If we were talking about a language with more focus on a smaller API rather than readability, I would agree with all the opposing arguments presented so far.

----------------------------------------
Feature #17830: Add Integer#previous and Integer#prev 
https://bugs.ruby-lang.org/issues/17830#change-91711

* Author: rafasoares (Rafael Soares)
* Status: Open
* Priority: Normal
----------------------------------------
I think `Integer#pred` is great as the inverse of `#succ`, but it reads a bit weird as the inverse of `#next`, which might be preferable for those going for a more "reads like English" approach.

On that note, `#previous` reads better, but it's also twice as long as `#pred` (or even `#next`). Which is why I've also added the shorthand `#prev`

Since Ruby strives for readability, I always thought it was weird that the team omitted this improvement. 

Also, I thought about writing a gem for this, but:
1. Do we really want to add another gem for such a simple change to every project?
2. Monkey-patching gems feel dirty.

Finally, I want to mention that I tried looking for previous discussions on this topic, as it seems likely someone would've brought this up at some point, but was unsuccessful. Probably due to the massive amount of baggage in the core issue tracker and mailing lists, I could've missed something among the noise.

I've created a fork on GitHub (https://github.com/rafasoares/ruby/commit/05119848b1f480db2e809f964528799030cc7ebb) in order to open a PR, but decided to open this ticket as well, after reading the contributing guide more carefully. 



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>