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…” 
John Pritchard-williams wrote:
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.
On Thu, Aug 28, 2008 at 11:25 PM, Joel VanderWerf
[email protected] wrote:
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
–
http://ruby-smalltalk.blogspot.com/
There’s no one thing that’s true. It’s all true.
Yes, that really freaked me out the first time it happened to me…
Need n = m.dup
On Thu, Aug 28, 2008 at 10:48 PM, Martin DeMello
[email protected] wrote:
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.
On Thu, Aug 28, 2008 at 2:43 PM, Robert D. [email protected]
wrote:
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
… 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 M. wrote:
… 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
On Thursday 28 August 2008 16:25:59 Joel VanderWerf wrote:
John Pritchard-williams wrote:
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.
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.
On Fri, Aug 29, 2008 at 7:27 AM, David M. [email protected]
wrote:
On Thursday 28 August 2008 16:25:59 Joel VanderWerf wrote:
John Pritchard-williams wrote:
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.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
On Fri, Aug 29, 2008 at 12:04 AM, Robert D. [email protected]
wrote:
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.
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.
Hi –
On Fri, 29 Aug 2008, Robert D. wrote:
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 ;).
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
On Aug 28, 11:43 pm, Robert D. [email protected] wrote:
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
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
John Pritchard-williams wrote:
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] = 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
Roger P. wrote:
David M. wrote:
… 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.
Ruby doesn’t use ++ because that would .succ!
On 29 Aug 2008, at 08:04, Robert D. wrote:
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 ;).
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
On Fri, Aug 29, 2008 at 10:10 AM, Lars C. [email protected]
wrote:
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.
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.
On Fri, Aug 29, 2008 at 3:25 PM, Phlip [email protected] wrote:
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.
–
http://ruby-smalltalk.blogspot.com/
There’s no one thing that’s true. It’s all true.
Hi,
John Pritchard-williams wrote:
There’s must be very good simple reason why there is no ‘x++’ method
Ruby right?
Because I’m planning to add a new comment beginning, ‘–’, like
BCPL, ADA, SQL and others. Then that must be the comment end. 
David M. wrote:
On Thursday 28 August 2008 16:25:59 Joel VanderWerf wrote:
John Pritchard-williams wrote:
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.
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?
The answer is much simpler than people are turning it into: hopefully
this will explain the problem beyond argument (whether it’s a sound
decision is another, much hairier topic).
Certain objects, like Fixnums, nil, and Symbols have a fixed object_id.
One can demonstrate this in irb quite simply:
irb(main):001:0> 1.object_id
=> 3
irb(main):002:0> 1.object_id
=> 3
irb(main):003:0> “foo”.object_id
=> 69836108895520
irb(main):004:0> “foo”.object_id
=> 69836108877060
irb(main):005:0> :bar.object_id
=> 332028
irb(main):006:0> :bar.object_id
=> 332028
irb(main):007:0> nil.object_id
=> 4
irb(main):008:0> nil.object_id
=> 4
irb(main):012:0> 1.succ.object_id
=> 5
irb(main):013:0> 2.object_id
=> 5
1.succ actually returns the object for Fixnum ‘2’, which is a different
object id, but is still immutable. Notice how out of all of those calls,
the only similar object with different object id’s is the string. Of all
of these, String objects are the only ones that are mutable (via
String#replace and whatnot).
1++ would have to operate (essentially) like 1.succ!, which would modify
the object itself. However, because of Fixnum’s implementation, 1++
would create a situation that would be hard to reconcile: does it change
the object to the Fixnum 2 (and preserve the object id for 1,
effectively rendering 1 == 2), does it create a new object that equates
to 2 (making 2 == 2 increase in complexity) or the current Fixnum
somehow needs to be encapsulated so that each Fixnum creation would be
mutable at some point.
Logically the last 2 situations are possible but in practice they would
be extremely slow, especially if those classes were malleable by ruby
programs.
The reality is that Ruby could support ++ for mutable objects (as
described elsewhere in this thread) for other objects (Float, for
example, creates mutable objects), but I personally believe that would
take confusion to a whole new level when it didn’t work on Fixnums.
HTH,
-Erik
Erik H. wrote:
1++ would have to operate (essentially) like 1.succ!, which would modify
the object itself.
If we’re considering this as an analogy to C, it doesn’t work that way.
In C, ++ doesn’t operate on integers, it operates on “lvalues”, which
include integer-valued variables. To illustrate:
$ cat >inc.c
main(){1++;}
$ gcc inc.c
inc.c: In function ‘main’:
inc.c:1: error: invalid lvalue in increment
It might be conceivable for ruby to have a ++ syntax that “operates on
variables” (to use the somewhat muddled phrase I used in an earlier
post). But there are very few syntaxes in ruby that operate on variables
(assignment is one, and defined?() might be considered another), so this
would be a radical and IMO distasteful change.