2009/10/30 RichardOnRails <RichardDummyMailbox58407 at (no spam) uscomputergurus.com>:

I'll correct my errors and probably have a new theory subsequently.

IMHO the story goes like this: absence of postfix ++ and -- is a
consequence of the fact that numeric types are immutable in Ruby which
makes an assignment necessary for these operators.  Although that
would be doable, it would not immediately be obvious when looking at
"foo++".  On the other side, "foo += 1" makes the assignment obvious
while still being pretty concise (you do not have to write "foo = foo
+ 1").

can you extol

your knowledge on me about what method_missing is doing?

On Fri, Oct 30, 2009 at 11:05 AM, Robert Klemme
shortcutter at (no spam) googlemail.com> wrote:
2009/10/30 RichardOnRails <RichardDummyMailbox58407 at (no spam) uscomputergurus.com>:

I'll correct my errors and probably have a new theory subsequently.
IMHO the story goes like this: absence of postfix ++ and -- is a
consequence of the fact that numeric types are immutable in Ruby which
makes an assignment necessary for these operators. Although that
would be doable, it would not immediately be obvious when looking at
"foo++". On the other side, "foo += 1" makes the assignment obvious
while still being pretty concise (you do not have to write "foo = foo
+ 1").

I think that theres a more fundamental problem with ++ in a language
like ruby, which has to do with the difference between objects and
variables.

The c ++ and -- operators change a variable, NOT a value.

so in C

a = 1
b = a
a++

a is now 2, but b is still 1.

Now, consider not immutable objects, but defining ++ for a mutable
object. I've named the method plus_plus instead of ++ since I can do
the former, but not the latter.

class String
def plus_plus
self << " plus a plus"
end
end


a = "A non-plussed string"
b = a

puts "a is #{a.inspect}"
puts "b is #{b.inspect}"

a.plus_plus

puts "a is #{a.inspect}"
puts "b is #{b.inspect}"

When we run this we see that the result is:

a is "A non-plussed string"
b is "A non-plussed string"
a is "A non-plussed string plus a plus"
b is "A non-plussed string plus a plus"

Because in languages like Ruby with object reference variable
semantics, methods can only operate on objects, not the variables
which reference them.

So if you COULD successfully define Fixnum#++, or Fixnum#plus_plus:

a = 1
a++

could only change the singleton instance of 1 into 2, which probably
isn't something you'd really want to do.

* Robert Klemme <shortcutter at (no spam) googlemail.com> (23:19) schrieb:

Yes - and in C++ you can have it otherwise:

robert at (no spam) fussel:~$ g++ x.cc && ./a.out
a++=1
a=2
b=2
robert at (no spam) fussel:~$ cat x.cc

#include <stdio.h

int main( int argc, const char* argv[] )
{
  int a = 1;
  int &b = a;
  printf("a++=%d\n", a++);
  printf("a=%d\n", a);
  printf("b=%d\n", b);
  return 0;
}

No, you can't:

$ ./ab
a: 2 at (no spam) 0xbfe413f8
b: 2 at (no spam) 0xbfe413f8

$ cat ab.cc
#include <iostream

int main(void) {
 int a = 1;
 int &b = a;
 a++;
 std::cout << "a: " << a << " at (no spam) " << &a << std::endl;
 std::cout << "b: " << b << " at (no spam) " << &b << std::endl;
 return 0;
}

There is only one variable, b is just another name for it.

2009/10/30 RichardOnRails <RichardDummyMailbox58... at (no spam) uscomputergurus.com>:

I'll correct my errors and probably have a new theory subsequently.

IMHO the story goes like this: absence of postfix ++ and -- is a
consequence of the fact that numeric types are immutable in Ruby which
makes an assignment necessary for these operators.  Although that
would be doable, it would not immediately be obvious when looking at
"foo++".  On the other side, "foo += 1" makes the assignment obvious
while still being pretty concise (you do not have to write "foo = foo
+ 1").

Which brings us to the question: what is the advantage of immutable
numbers?  First, it avoids errors that could be caused by aliasing
(two objects refer the same object, one of them changes it, it changes
for the other one as well without being expected).  Then, it is quite
natural if you consider mathematical numbers: they cannot change.

Additionally, the expression "1" can always refer to the same object
(in reality it's a bit different but from a Ruby programmer's
perspective the difference is not noticeable) which in fact makes
using numeric constants very efficient (as opposed to the expression
"'foo'" which constructs a new String instance on every invocation,
albeit with a shared char array underneath which eases the pain a
bit).

This in turn makes integer math pretty efficient because if numbers
were mutable Ruby would have to create a new object for every result
of an operator evaluation.  I am not saying that Ruby is ideal for
number crunching but it could be significantly slower if certain
design decisions would have been made differently.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestpractices.com/

Maybe I am missing something

[Note: parts of this message were removed to make it a legal post.]

On Fri, Oct 30, 2009 at 12:03 PM, Rick DeNatale <rick.denatale at (no spam) gmail.com>wrote:

I think that theres a more fundamental problem with ++ in a language
like ruby, which has to do with the difference between objects and
variables.


Personally I see nothing interesting about the behavior of ++ in any mutable
state language.


Now, consider not immutable objects, but defining ++ for a mutable
object. I've named the method plus_plus instead of ++ since I can do
the former, but not the latter.


How is ++ any different from << except for << taking an argument? (given
hypothetical C-like ++ behavior)

There is already extensive precedent in Ruby for destructive method calls
that mutate state, and they all lead to the same confusion.

There is nothing interesting with Ruby in this regard, except that Ruby does
seem to go out of its way to do things immutably by default, which, in my
opinion, is pretty cool. But in the end Ruby is still very much a mutable
state language.

I think that theres a more fundamental problem with ++ in a language
like ruby, which has to do with the difference between objects and
variables.

Now, consider not immutable objects, but defining ++ for a mutable
object. I've named the method plus_plus instead of ++ since I can do
the former, but not the latter.

Why this wierd semantic? Because it the original use case was for
pointers rather than integers, and it goes back to C originating
originally as a kind of high level assembly language for the DEC
PDP-11 which had postincrement and predecrement addressing modes used
for stepping through strings or arrays.

Because pre-ANSI C allowed easy spoofing/overlay of types, it also
worked for integers and was used in contexts like for loops
for(i = 0; i < max;i++)

If you want the real semantics of the C/C++ post-increment operator,
I'm afraid you'll have to look for it in a C family language, not an
object reference semantic language like Ruby.

a += 1 is equivalent to a++’s natural meaning.  In fact, we further
supplement the above statements with:

class Fixnum
 def pp # We can’t define ++ because of a compiler restriction.
   self + 1
 end
end

So x++ works fine in the form of pp for positive Fixnum’s.  I assume
it’ll work fine for non-positives, also..  A compiler change to allow
“def ++” is necessary to finally add ++ to Fixnum.

-----Original Message-----
From: marnen at (no spam) marnen.org [mailto:marnen at (no spam) marnen.org]
Now consider the ruby way:

10.times do |i|
print "#{i},"
end

Some length as the C code, but much more readable. Heck, it's
almost English!


Well, you do have to know what Numeric#times yields to its block. But
that's easy to look up. (However, it starts from 0, so it's not quite
equivalent to the C.)

Not for me it wasn't. I had to try it to see that it actually works.
My initial impression was that it would print 10 copies of i.
I still don't see where 'i' is incremented

-----Original Message-----
From: marnen at (no spam) marnen.org [mailto:marnen at (no spam) marnen.org]
Now consider the ruby way:

10.times do |i|
print "#{i},"
end

Some length as the C code, but much more readable. Heck, it's
almost English!
Well, you do have to know what Numeric#times yields to its block. But
that's easy to look up. (However, it starts from 0, so it's not quite
equivalent to the C.)

Whoop! Good point, that's what I get for not actually testing my code.

Corrected (and even closer to English).

(1..9).each do |i|
print "#{i},"
end

Michael Wrote:
Not for me it wasn't. I had to try it to see that it actually works.
My initial impression was that it would print 10 copies of i.
I still don't see where 'i' is incremented

It isn't incremented, at least not in MY code (if you must think in
terms of incrementing variables, then Ruby is incrementing it for me)
See the times method at:
http://ruby-doc.org/core/classes/Integer.html
That kind of looping is a pretty core Ruby concept.

Also the corrected version I wrote above should be a bit clearer. Also
I think your previous programming experience is hurting you here. To you
as (I'm guessing) a C programmer, to progress in a loop, you must increment
modify variable. The average English speaker doesn't think in those terms.

I started with Fortran in the early 1980's, followed by Basic, Pascal,

Looking at my most recent example, the English equivalent would be for each
'i' from 1 to 9 print 'i' followed by a comma. Sure, the words may not be
in the precise order, but it comes a darn site closer to natural language than:

int i=1;
while (i<10)
{
printf("%d,",i++);
}

On Thu, Nov 5, 2009 at 3:40 AM, Gavin Sinclair <gsinclair at (no spam) gmail.com> wrote:

def ++
incrementing_logic_goes_here
end

I could see this as being handy

What's wrong with

def inc
incrementing_logic_goes_here
end

How is that any different?


What's wrong with Array#push? Why do we need Array#<<? How is that any
different?

-----Original Message-----
From: marnen at (no spam) marnen.org [mailto:marnen at (no spam) marnen.org]
Now consider the ruby way:

10.times do |i|
print "#{i},"
end

Some length as the C code, but much more readable. Heck, it's
almost English!