Please don't flame me...why is there no "++" in Ruby again ?

[John Pritchard-williams]

There's must be very good simple reason why there is no 'x++' method
Ruby right?

Just generally interested why there isn't....

I did check my Ruby books by the way, but they just "unlike C there is
no ++ operator in Ruby...."

 

[Joel VanderWerf]

There's must be very good simple reason why there is no 'x++' method
Ruby right?

Just generally interested why there isn't....

I did check my Ruby books by the way, but they just "unlike C there is
no ++ operator in Ruby...."

In ruby, operators are methods and they operate on objects, not on
variables.

 

[Robert Dober]

In ruby, operators are methods and they operate on objects, not on
variables.

... and as Integers are immutable ++ cannot change the underlying object.
One could define ++ if one wanted, but it can only work on mutable objects

class MyInteger
def initialize int; @int = int end
define_method "++" do @int += 1 end
def to_s; @int.to_s end
end

m = MyInteger.new 41
puts m
m.send "++"
puts m


Cheers
Robert

 

[Martin DeMello]

One could define ++ if one wanted, but it can only work on mutable objects

class MyInteger
def initialize int; @int = int end
define_method "++" do @int += 1 end
def to_s; @int.to_s end
end

m = MyInteger.new 41
puts m
m.send "++"
puts m

Also note that this will not do what you expect from other languages

m = MyInteger.new 41
n = m
puts m
puts n
m.send "++"
puts m
puts n

martin

 

[Nedry]

Yes, that really freaked me out the first time it happened to me...
Need n = m.dup

Also note that this will not do what you expect from other languages

m = MyInteger.new 41
n = m
puts m
puts n
m.send "++"
puts m
puts n

martin

--
Peter: I'll handle it, Lois. I read a book about this sort of thing once.

Brian: Are you sure it was a book? Are you sure it wasn't nothing?

Peter: Oh yeah.

 

[John Pritchard-williams]

... and as Integers are immutable ++ cannot change the underlying object..

That makes sense : and I guess 'x++'=> x+1 would be just confusing..

I mean like this:

a+=1 (which of course IS valid)

a++ - could in theory mean "Take the value pointed at by a currently,
increment it and re-point 'a' at that new object"...

but then people might abuse it and not realize (as I hadn't really) that
Integers are immutable...and give the garbage collector a really hard
time...

Cheers

John

 

[David Masover]

In ruby, operators are methods and they operate on objects, not on
variables.

That's not really a valid reason, and not entirely true -- there is no +=
method for you to define. It behaves as though it's a macro:

foo += 1
#becomes
foo = foo + 1

I see no reason there couldn't be a ++ operator that behaves the same way:

foo ++
# becomes
foo += 1
# or, probably better:
foo = foo.succ

You can define foo=, and you can define +, but you can't define +=.
Why not add a ++ that works the same way += does?


... Then again, why pollute our namespace with an operator that would see so
little use? I can't remember the last time I had to use "+=1" in Ruby.

 

[Roger Pack]

... Then again, why pollute our namespace with an operator that would
see so
little use? I can't remember the last time I had to use "+=1" in Ruby.

I wish we had it. But that's just me.
-=R

 

[Robert Dober]

That's not really a valid reason, and not entirely true -- there is no +=
method for you to define. It behaves as though it's a macro:

You are right of course, the original question was, why is there no
x++ as syntactic sugar for x = x + 1.
No idea .
Cheers
Robert

 

[Christopher Dicely]

You are right of course, the original question was, why is there no
x++ as syntactic sugar for x = x + 1.

Because Ruby is hard enough to parse as it is. After all, ++x is
already valid Ruby. equivalent to x.send"+@").send"+@"). And x++x
is valid (though odd) Ruby, equivalent to x.+(x.send"+@")).

Its probably better to just let people use x+=1.

 

[Lars Christensen]

.. and as Integers are immutable ++ cannot change the underlying object.
One could define ++ if one wanted, but it can only work on mutable objects

I think the OP deserves the fuller explanation; Why are integers
immutable? Consider this:

a = 2
b = a
a++

Since everything is an object, 'a' references the object '2' and b
should reference it too after the assignment. Then 'a++' should
increment the object referenced by both a and b? This would of course
be possible, but it would be a rather huge performance penalty to keep
something as simple as integers as references to objects everywhere.

Ruby keeps 'small-enough' integers in the object reference (pointer)
to improve performance. Hence 'b = a' results in an actual copy being
taken of the value '2'. If you increment 'b', 'a' would retain its old
value, breaking the concept that a variable is always just a
reference. Ruby opts for immutable Integers instead.

Lars

 

[David A. Black]

Hi --

You are right of course, the original question was, why is there no
x++ as syntactic sugar for x = x + 1.
No idea .

Matz has always said that the reason is that he doesn't like the idea
of an assignment that looks like incrementation. In other words, if
you did:

x = 1
x++

you wouldn't be incrementing x (because then 1 would be 2, which would
cause chaos); rather, you would be assigning to x. Wrapping that in a
notation that typically means something different (incrementing a
variable) would be unidiomatic and misleading.


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!

 

[Frederick Cheung]

You are right of course, the original question was, why is there no
x++ as syntactic sugar for x = x + 1.
No idea .

Although it usually isn't quite the same as just x = x + 1 (that's
more like ++x) so it's slightly more tricky that just +=

Fred

 

[Dave Bass]

There's must be very good simple reason why there is no 'x++' method
Ruby right?

The problem with the ++ operator, and similar operators, is that the
side effects can be unpredictable.

Kernighan and Ritchie, 2nd ed., have this to say:

"In any expression involving side effects, there can be subtle
dependencies on the order in which variables taking part in the
expression are updated. One unhappy situation is typified by the
statement

a = i++;

The question is whether the subscript is the old value of i or the new.
Compilers can interpret this in different ways, and generate different
answers depending on their interpretation."

In Ruby there's only one compiler (no formal language definition, just a
single implementation), unlike C. But there's still the point that the
semantics of the statement may be unclear to the programmer.

Dave

 

[Phlip]

I wish we had it. But that's just me.

Ruby doesn't use ++ because that would .succ!

 

[Robert Dober]

I think the OP deserves the fuller explanation;

You are right, but I did after realising my error .
AAMOF it has *nothing* to do with the immutability of integers.
OP asked for syntactic sugar.

Why are integers
immutable? Consider this:

a = 2
b = a
a++

Since everything is an object, 'a' references the object '2' and b
should reference it too after the assignment. Then 'a++' should
increment the object referenced by both a and b? This would of course
be possible, but it would be a rather huge performance penalty to keep
something as simple as integers as references to objects everywhere.

Ruby keeps 'small-enough' integers in the object reference (pointer)
to improve performance. Hence 'b = a' results in an actual copy being
taken of the value '2'. If you increment 'b', 'a' would retain its old
value, breaking the concept that a variable is always just a
reference. Ruby opts for immutable Integers instead.

Nevertheless all you said makes perfect sense of course.
R.

 

[Robert Dober]

Ruby doesn't use ++ because that would .succ!

No it would not, and if you have good memories you know who was the
fool who proposed succ! once, LOL.
The worst is that this confusion is totally my fault because I was
talking about Integer's immutability completely out of context.
Sorry.
R.