Why no next! method in integer class ?

[bradjpeek]

Just curious...

The string class contains a next! method. Is there a technical
reason for not having a next! method in the integer class, or was it
just a language designer preference?

 

[Trans]

Just curious...

The string class contains a next! method. Is there a technical
reason for not having a next! method in the integer class, or was it
just a language designer preference?

Integer is immutable.

T.

 

[dblack]

Hi --

Just curious...

The string class contains a next! method. Is there a technical
reason for not having a next! method in the integer class, or was it
just a language designer preference?

Probably both The technical reason is that integers are immediate
values, so you can't increment them. In other words:

a = 1
a.next!

That would mean that 1 is now 2, which would not be good. In theory
you could change the binding of a, so that it was now bound to 2
instead of 1; but that's out of keeping with how these things
generally work (e.g., with strings), which is that the object is
mutated while the variable bindings are not affected. Doing it this
way reinforces how objects and variables relate to each other in Ruby,
and avoids having assignments that are masquerading as method calls.

For more on this, search the archives for discussions on ++, which is
absent from the language for very similar reasons.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Robert Dober]

Hi --



Probably both The technical reason is that integers are immediate
values, so you can't increment them. In other words:

a = 1
a.next!

That would mean that 1 is now 2, which would not be good. In theory
you could change the binding of a, so that it was now bound to 2
instead of 1; but that's out of keeping with how these things
generally work (e.g., with strings), which is that the object is
mutated while the variable bindings are not affected. Doing it this
way reinforces how objects and variables relate to each other in Ruby,
and avoids having assignments that are masquerading as method calls.

For more on this, search the archives for discussions on ++, which is
absent from the language for very similar reasons.

Too kind of you David to omit my stupid RCR suggestion of
Integer#succ! and Integer#pred!, but it is worth searching for it as
things were explained very well in that thread.

BTW I am much smarter now

Robert