On Tue, 26 Nov 2002 09:21:48 +0900, Daniel Carrera wrote:
>> And given that the concept of 'x++' is very rarely needed in a
>> Ruby program, having iterators instead of for-loops, those extra
>> three characters are actually a very small percentage, amortised
>> over the entire program.
> Regardless, is there a reason *not* to have '++'? It's the kind of
> shortcut that many programmers expect and I just can't think of
> any reason not to have it.

It's applicable to a small subset of the total set of classes.
Really, x++ is the same as x.succ!, and x.succ! won't work because
there's no assignment and you can't change self.

Remember that Fixnums are immediate/singleton objects (there is one
and only one instance of the Fixnum object with value 5), so you
couldn't have x.succ! (or x++) do anything meaningful -- again,
because "self" cannot be changed, even if x.succ! was meaningful for
other objects.

If it's "magicked" to x += 1 (which itself is magic for x = x + 1),
then you run into the problem of applicability to non-Numeric
classes.

All in all, it's a shorthand that doesn't really make sense in Ruby.

Speaking of which, wouldn't the "best" Ruby idiom for:
    x += 1
really be:
    x = x.succ
? This, at least, would work cleanly with any "countable" object. I
think.

> Following the principle of Least Surprise, I'd expect to find this
> feature, unless there is a good reason to avoid it.

Ruby is really designed to the Princple of Matz's Least Surprise.
Ruby works 95% of the time for me with no surprises, but I'm not
Matz, so there will always be some surprise there for me. Usually
pleasant.

IMO, there are good reasons to avoid x++ (aside from the fact that
it really to modifies "self", which I really think is a bad idea).
The main reason to avoid it is that it isn't really needed in Ruby.
In the Ruby that I've done so far, Text::Format uses it in one
place, which would be removed if I switch to any of the
Array#zip/Array#braid methods proposed recently; in RTidy/CityDesk I
use it extensively to add to the progress (which means I should
probably refactor the progress handling into its own class) for the
progress bar calculations.

Everything else is done with native Ruby loops -- I find that I just
*don't care* about incrementing indexes, because Ruby does the right
thing for me.

-austin
-- Austin Ziegler, austin / halostatue.ca on 2002.11.25 at 21.46.33