On Sun, Nov 8, 2009 at 11:48 AM, Tony Arcieri <tony / medioh.com> wrote: > On Fri, Nov 6, 2009 at 4:30 PM, Seebs <usenet-nospam / seebs.net> wrote: > >> "variables aren't objects" > > > I've seen this mentioned a few times. ¨Â ôèéîéô§ó óïíåôèéîïæ çòïó> misstatement of a problem, and a deeper understanding might be able to peel > away some of the layers of the debate here. > > I can't think of a language where "variables are objects". ¨Âîä ôèéó éóî§> the issue. In C++ a variable can actually hold the state of an object rather than simply a reference to the object. If you think of object as simply meaning what holds the state of what is denoted by a variable, then C variables hold objects, and since a pointer represents state, even pointer's can be considered objects in this degenerate (if you will) form. And that really is the point with the ++ operator, at least if you want it to have the semantics of C/C++. the c/c++ expression b = a++ has the meaning. 1) copy the current contents of the a variable to b 2) increment the contents of the variable a according to the static type of a, e.g. if it's an int or a pointer to a char add 1 to it, if it's a pointer to a (4-byte) int add 4 to it, etc. The original quest in this thread was to do this by defining a ++ method for FixNum (or Integer). As Matz himself has pointed out in this thread, > > There's no way to modify local variables by sending message in Ruby. > > matz. Which is something I've said on this thread before (multiple times IIRC). This has nothing to do with whether or not the object bound to a variable is immutable, it has to do with how ruby variable bindings can and cannot be changed, and that is the whole point. Now, while it's true that Fixnums have a property of being represented by an immediate value rather than a pointer to a 'boxed' value, and this is possible because they are immutable, it doesn't mean that local variables with non-immediate bindings can be rebound inside the invocation of another method. The only way to define b = a++. in Ruby with C/C++ semantics would be to alter the parser to treat such expressions as syntactic sugar, (which was Charle's proposal), much like += is handled now. Let's say this were done, perhaps by the parser treating: b = a++ as if it were b, a = a, a.succ much like it treats a += 1 as if it were a = a + 1 The actual parser changes would need to be sensitive to other cases like foo(b + a++) which would need to compute a + b before incrementing a. One could alter what the increment did, by redefining succ or a particular class, much like redefining + for a given class can alter the value of a + 1 for a particular binding of a. But one could still not move the actual change of binding into a method, any more than you can redefine the '=' part of '+=' -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale